Chapter 9: FINDING FAULT Debugging: What to Do When Things Go Wrong

• Build your code with all compiler warnings switched on. It will highlight potential problems before they can bite.
• Always follow the golden rule of debugging: Use your brain.
• Set a reasonable time limit for “unstructured” debugging, and then resort to more methodical approaches if you don’t find success.
• Learn the code you’re debugging—you can’t expect to find errors in code you don’t understand.
• When you look for a fault, suspect everything. Eliminate even the unlikeliest of causes first, rather than presume they have nothing to do with it. Assume nothing.
• When your build fails, look at the first compiler error. Trust this far more than the subsequent messages.
• Debugging is a methodical activity, slowly closing in on the location of a fault. Don’t treat it like a simple guessing game.
• The first step to locating a fault is finding out how to reproduce it reliably.
• Start from what you know—the point of a program crash, for example. Then work back from there to the cause of the failure.
• Once you think you’ve found the cause of a bug, investigate it thoroughly to prove that you are right. Don’t blindly accept your first hypothesis.
• Fix bugs with the utmost care. Don’t risk breaking anything else with your modification.
• When you fix a bug, check to see if the same mistake is lurking in related sections of code. Exterminate the bug once and for all: Fix all occurences of the fault now.
• With each fault you fix, learn the lessons. How could you have prevented it? How could you have discovered it more quickly?
• Use debuggers sparingly, when you encounter behavior you can’t explain. Don’t reach for them routinely to use as an alternative to understanding how your code works.