How to most effectively debug code?

Question

Bugs creeping into code can be minimized, but not entirely eliminated as it is written - programmers are, although many would disagree, only humans.

When we do detect an error in our code, what can we do to weed it out? How should we approach it to make most effective use of our valuable time and enable us to spend less time trying to find it and more time coding? Also, what should we avoid when debugging?

Note here that we're not talking about preventing bugs; we're talking about what to do when bugs do appear. This is a wide field, I know, and may be highly dependent on language, platform and tools. If so, keep to encompassing answers such as mindsets and general methods.

Answer 1

The mindset and attitude to debugging is perhaps the most important part, because it determines how effectively you'll fix the error, and what you'll learn from it — if anything.

Classics on software development like The Pragmatic Programmer and Code Complete basically argue for the same approach: every error is an opportunity to learn, almost always about yourself (because only beginners blame the compiler/computer first).

So treat it as a mystery which will be interesting to crack. And cracking that mystery should be done systematically, by expressing our assumptions (to ourselves, or to others) and then testing our assumptions, one-by-one if need be — using every tool at our disposal, especially debuggers and automated test frameworks. Then after the mystery is solved, you can do even better by looking through all your code for similar errors you may have made; and write an automated test to ensure the error will not happen unknowingly again.

One last note - I prefer to call errors "errors" and not "bugs" - Dijkstra chided his colleagues for using the latter term because it's dishonest, supporting the idea that pernicious and fickle bug-fairies planted bugs in our programs while we weren't looking, instead of being there because of our own (sloppy) thinking: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error).

Answer 2

1. Write tests. Testing is not only great at preventing bugs (in my experience, TDD done right eliminates almost all trivial, stupid bugs), but also helps a lot in debugging. Testing forces your design to be rather modular, which makes isolating and replicating the problem a lot easier. Also, you control the environment, so there will be a lot less surprises. Moreover, once you get a failing test case, you can be reasonably sure that you've nailed the real reason of the behavior that is bothering you.

2. Learn how to use a debugger. print statements may work reasonably well at some level, but a debugger most of the time is very helpful (and once you know how to use it, it is a lot more comfortable than print statements).

3. Talk about someone about your problem, even if it's just a rubber duckie. Forcing yourself to express the problem you are working on in words really does miracles.

4. Give yourself a time limit. If for example after 45 minutes you feel you are going nowhere, just switch to other tasks for some time. When you get back to your bug, you'll hopefully be able to see other possible solutions that you wouldn't have have considered before.

Answer 3

I think the reproduction of a bug is also important. All cases which reproduce the bug can be listed and then you can make sure that your bug fix covers all those cases.

Answer 4

There is an excellent book I read on this subject called Why Programs Fail, which outlines various strategies for finding bugs ranging from applying the scientific method to isolate and resolve a bug, to delta debugging. The other interesting part of this book is that it does away with term 'bug'. Zeller's approach is:

(1) A programmer creates a defect in the code. (2) The defect causes an infection (3) The infection propagates (4) The infection causes a failure.

If you want to improve your debugging skills, I highly recommend this book.

In my own personal experience, I've found plenty of bugs in our application, but management simply presses us onwards to get new features out. I've frequently heard "We found this bug ourselves and the client hasn't noticed it yet, so just leave it until they do". I think being reactive opposed to proactive in fixing bugs is a very bad idea as when the time comes to actually put a fix in, you've got other issues that need resolved and more features management want out the door ASAP, so you get caught in a vicious cycle that can lead to a great deal of stress and burn out and ultimately, a defect ridden system.

Communication is also another factor when bugs are found. Sending an email out or documenting it on the bug tracker is all fine and well, but in my own experience, other developers find a similar bug and rather than reuse the solution you put to fix the code (as they've forgotten all about it), they add their own versions, so you've got 5 different solutions in your code and it looks more bloated and confusing as a result. So, when you do fix a bug, make sure a few people review the fix and give you feedback in case they have fixed something similar and found a good strategy to dealing with it.

limist mentioned the book, The Pragmatic Programmer which has some interesting material on fixing bugs. Using the example I gave in the previous paragraph, I'd look at this: Software Entrophy, where the analogy of a broken widow is used. If two many broken windows appear, your team may become apathetic towards ever fixing it unless you take a proactive stance.

Answer 5

Blockquote When we do detect an error in our code, what can we do to weed it out? How should we approach it to make most effective use of our valuable time and enable us to spend less time trying to find it and more time coding? Also, what should we avoid when debugging? Blockquote

Assuming that you are in a production environment, here is what you need to do: 1. Describe the "error" correctly and identify the events that cause it to happen.

1. Determine if the "error" is a code error or specification error. For example, entering 1 letter name may be considered an error to some systems and acceptable behavior for others. Some times a user would report an error that he/she thinks but that behavior of the system was not part of the requirements.

2. If you have proved that the error is due code, which code pieces need to be fixed to prevent the error. Also examine the effect of the behavior on current data and future system operations (impact analysis on code and data).

3. At this point you would probably have an estimation of how much resources are going to be consumed to fix the bug. You either fix it as soon or schedule its fix on a next coming release of the software. This depends also on the whether the end user is willing to pay for the fix. You should also evaluate different available options to fix the error. There may be more than one way. You need to select the 'best' that suits the situation.

4. Analyze the reasons that caused this bug to appear (requirements, coding, testing, etc.) - Enforce processes that would prevent the condition from happening again.

5. Document the episode adequately.

6. Release the fix (or the new version)

Answer 6

Here's how I do it:

1. use the same method every time to find the problem. This will improve your reaction time to the errors.
2. Best way is probably reading the code. This is because all the information is available in the code. You just need efficient ways to find correct position and ability to understand all the details.
3. debugging is very slow way, and only necessary if your programmers do not yet understand how computer executes asm instructions/cannot understand call stacks and basic stuff
4. Try to develop proof techniques like using function prototypes to reason about behaviour of the program. This will help finding the correct position faster