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.
Jun 07, 2010