Metzger - Debugging by Thinking
Here you can read online Metzger - Debugging by Thinking full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. year: 2003;2004, publisher: Elsevier Ltd.;Elsevier Science, genre: Computer. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:
Romance novel
Science fiction
Adventure
Detective
Science
History
Home and family
Prose
Art
Politics
Computer
Non-fiction
Religion
Business
Children
Humor
Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.
- Book:Debugging by Thinking
- Author:
- Publisher:Elsevier Ltd.;Elsevier Science
- Genre:
- Year:2003;2004
- Rating:4 / 5
- Favourites:Add to favourites
- Your mark:
Debugging by Thinking: summary, description and annotation
We offer to read an annotation, description, summary or preface (depends on what the author of the book "Debugging by Thinking" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.
Metzger: author's other books
Who wrote Debugging by Thinking? Find out the surname, the name of the author of the book and a list of all author's works by series.
![Tarik Soulami - Inside Windows debugging: [practical debugging and tracing strategies]](/uploads/posts/book/240776/thumbs/tarik-soulami-inside-windows-debugging.jpg)
Debugging by Thinking — read online for free the complete book (whole text) full work
Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Debugging by Thinking" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.
Font size:
Interval:
Bookmark:
Robert Charles Metzger
Digital Press is an imprint of Elsevier.
Copyright 2004, Hewlett-Packard Development Company, L.P. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher.
All trademarks found herein are property of their respective owners.
Recognizing the importance of preserving what has been written, Elsevier prints its books on acid-free paper whenever possible.
Library of Congress Cataloging-in-Publication Data
Metzger, Robert C.
Debugging by thinking : a multidisciplinary approach/Robert Charles Metzger.
p. cm.
ISBN: 1-55558-307-5
1. Debugging in computer science. I. Title.
QA76.9.D43M48 2003
005.14dc22
2003055655
British Library Cataloguing-in-Publication Data
A catalogue record for this book is available from the British Library.
The publisher offers special discounts on bulk orders of this book.
For information, please contact:
Manager of Special Sales
Elsevier
200 Wheeler Road
Burlington, MA 01803
Tel: 781-313-4700
Fax: 781-313-4882
For information on all Digital Press publications available, contact our World Wide Web home page at: http://www.digitalpress.com or http://www.bh.com/digitalpress
10 9 8 7 6 5 4 3 2 1
Printed in the United States of America
For my family Marcia, Erika, and Benjamin who make it all worthwhile.
When I first learned to program, I found the process of testing and debugging very frustrating. I can remember slamming my fist down on the hard metal shell of the Selectric typewriters we used to interact with the timesharing system at the amazing speed of 15 characters per second. The bugs didnt disappear any more quickly for the beating. None of my professors taught me anything about testing and debugging that I can remember.
During the nearly 30 years that I have worked in software development, many aspects of the profession have changed. Languages have become popular and gone out of favor. Better development methodologies have been introduced, only to be replaced by yet more sophisticated methodologies. Microprocessors have become ubiquitous, and software has become the driving force behind many new products. The laptop computer that I wrote this book on has a faster processor, more memory, and more disk space than the multimillion dollar IBM mainframe on which I learned to program.
Some things have not changed, however. Software products still contain far too many bugs. Software developers still spend far too much time finding and fixing those bugs. People who are learning to program spend far too much time struggling to learn by trial and error.
I wrote this book because I wanted to introduce a systematic approach to debugging to a wide audience. If you learn something from this book that enables you to find and fix bugs more quickly, then I will have succeeded.
This book was written with both students and professional programmers in mind. Any student who has completed a course in computer programming and a course in data structures and algorithms should be able to understand and apply the material in this book. Professional programmers should find new ideas to make them more productive, along with new twists on old ideas they have been using for years.
The case studies were done in C++ and Java because they were the most popular programming languages in use when this book was written. I refer to other popular languages, particularly C and Fortran, when they are relevant to a particular topic. Since this book focuses on how to think about debugging, rather than on specific platforms, almost all of the material is relevant to all programming languages. If your primary language is not Java or C++, you should still be able to apply at least 90 percent of the material in this book.
There are several reasons that this book takes a multidisciplinary approach to debugging. One reason is that people are unique, and different people have different preferred modes of learning. Some people need to see things to learn, others prefer to hear new material, and others have trouble understanding unless they can work something with their hands. In a similar way, some people will relate to some of the lessons of certain disciplines better than others.
When the material in this book was presented in classes for computer science graduate students, I found a wide difference in which disciplines the students found most interesting or helpful. Some absolutely loved the analogy to detective literature. Others were uninterested. Some were fascinated by the study of human error. Others had trouble seeing how it was relevant to them. If you have problems relating to the analogy of one particular discipline, move on to another one, and come back later to the first one.
after that.
). If you arent sure whether a chapter will be of use to you, read the review at the end of the chapter first.
applies ideas from cognitive psychology that attempt to explain how programmers create bugs.
, and make a plan for applying what you have read.
Italics are used to emphasize a point and identify the names of publications and products.
Boldface is used to introduce new terms, which are collected in the glossary, and to distinguish programming language keywords and commands from the text.
Example material that is computer generated, such as command-line entries and source code listings, is set in the following typeface:
This is a computer listing
Example material that isnt computer-generated, such as algorithm descriptions and debugging logs, is set in the following typeface.
This is a debugging log
Choosing the right third-person singular pronoun is a difficult task these days. In this book, unknown software developers are referred to as he or she.
Thanks to my wife Marcia for encouraging me to finish a book I had been talking about for 10 years. She suggested that I read the Lord Peter Wimsey mysteries, and the result is apparent in this book.
Thanks to Dr. Lawrence Rauchwerger, Dr. Nancy Amato, and their graduate students at Texas A&M University for giving me opportunities to present an early version of this material to them and for giving me valuable feedback on their classes.
Thanks to my managers at Hewlett-Packard, Betty van Houten, Steve Rowan, and Ty Rabe, who gave their permission for HP Books to publish this book.
Thanks to all the programmers I have worked with and managed at I.P. Sharp Associates, Convex Computer Corporation, and Hewlett-Packard. I learned both from your successes and failures in debugging complex systems.
Thanks to Ken Robinson and the technical support people at Parasoft, who gave me lots of help working with Insure++.
Thanks to my editor, Pam Chester, for taking on this project enthusiastically and carrying it through to completion professionally.
Font size:
Interval:
Bookmark:
Similar books «Debugging by Thinking»
Look at similar books to Debugging by Thinking. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.
Discussion, reviews of the book Debugging by Thinking and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.