Techniques for Finding Defects
- Use all the data available to make your hypothesis
- Refine the test cases that produce the error
- Exercise the code in your unit test suite
- Use available tools
- Reproduce the error several different ways
- Generate more data to generate more hypotheses
- Use the results of negative tests
- Brainstorm for possible hypotheses
- Narrow the suspicious region of the code
- Be suspicious of classes and routines that have had defects before
- Check code that’s changed recently
- Expand the suspicious region of the code
- Integrate incrementally
- Check for common defects
- Talk to someone else about the problem
- Take a break from the problem
- Set a maximum time for quick and dirty debugging
- Make a list of brute force techniques, and use them
Techniques for Syntax Errors
- Don’t trust line numbers in compiler messages
- Don’t trust compiler messages
- Don’t trust the compiler’s second message
- Divide and conquer
- Find extra comments and quotation marks
- Techniques for Fixing Defects
- Understand the problem before you fix it
- Understand the program, not just the problem
- Confirm the defect diagnosis
- Save the original source code
- Fix the problem, not the symptom
- Change the code only for good reason
- Make one change at a time
- Check your fix
- Look for similar defects
General Approach to Debugging
- Do you use debugging as an opportunity to learn more about your program, mistakes, code quality, and problem-solving approach?
- Do you avoid the trial-and-error, superstitious approach to debugging?
- Do you assume that errors are your fault?
- Do you use the scientific method to stabilize intermittent errors?
- Do you use the scientific method to find defects?
- Rather than using the same approach every time, do you use several different techniques to find defects?
- Do you verify that the fix is correct?
- Do you use compiler warning messages, execution profiling, a test framework, scaffolding, and interactive debugging?
Other Code Complete Resources: