4.3 Review

Don’t begin debugging by looking at source code or running the application in question. Begin by making a list of criteria to evaluate possible causes and a list of similar defects you have seen before.

A bug is a behavior that is as yet unexplained. It isn’t impossible to explain it; it has merely not yet been explained. A systematic searcher can tell you what he or she has already searched, what he or she is currently searching, and what remains to be searched.

The physical tension caused by squinting, sitting in unnatural positions, and other uncomfortable practices translates into mental tension. This tension isn’t conducive to thinking. If you use the methods in this book, you can have confidence that you will find the bug you’re analyzing.

Work backward from the code that evidences a defective value, through the computations that generate it, to the code that reads in the input values used in the computation, to the input values themselves.

The customary place for a bug to occur is the last place that was modified. To find the source of a defective value that has drifted down the data-flow graph, work backward from the manifestation to the definition.

It is possible to look right at a problem in code and not see it, because you confuse what you know the code is supposed to do with what it is actually doing. If you know that a given piece of code must be the source of a problem, but after a thorough investigation, you are unable to identify the source, you should just write the code over again.

You may have identified a particular code segment as the cause of a problem, yet be unable to see the problem source. There are a number of programming constructs that can place a problem out of view.

Thinking back is greatly aided by a record of your actions. Use one of several possible automatic ways you can keep track of what you did.

If you are going to ensure that you don’t visit a code segment more than once, it is important to keep a record of where you have looked so far.

Physical locality isn’t a primary concern when debugging software. Displacements of problems are more likely to occur temporally rather than spatially.

If you want to be a productive debugger, be a revision control fanatic. There are good source control systems publicly available. You can’t see changes that caused a problem if you can’t track the deltas.

After you have made a heroic effort to diagnose your problem, it is reasonable to consider whether your code may not be the culprit. If you want to get help with a problem in other people’s software, it is important to create a minimal test case that demonstrates the problem.