| Debugging C and C++ code in a Unix environment | ||
|---|---|---|
| Prev | Chapter 3. Aspects of debugging C and C++ code | Next |
Repairing a bug is more than modifying code. Make sure you document your fix properly in the code, and test it properly.
After repairing a bug, ask yourself what you can learn from it:
How did I notice this bug? This might help you to write a test case to detect it if it slips in again.
How did I track it down? This will give you better insight in which approach to take in case you encounter similar symptoms again.
What type of bug was it (see the section called Types of bugs)? Do I encounter this type often? If so, what can I do to prevent it from re-occurring?
What you learn is probably valuable not only to you in developing this particular piece of code. Try to communicate what you learned to your colleagues, for instance by writing it down in a pattern-like fashion (e.g. `IF you find your program foos bars AND it does not foo bazs THEN try frobbing it').
Quite often, we find that one of the main reasons why tracking down a bug takes so long, is that we have made unjustified assumptions about parts of our code [1] .
| [1] | One of Ray's experiences: Once, a memory allocation tool told me that there was a problem with my own string routines. I did not believe it. Some months later, I spent hours in tracking down a nasty bug to find it was an off-by-one error in my string copy routine, precisely where the tool complained. |