- Item 9: Set Yourself Up for Debugging Success
- Item 10: Enable the Efficient Reproduction of the Problem
- Item 11: Minimize the Turnaround Time from Your Changes to Their Result
- Item 12: Automate Complex Testing Scenarios
- Item 14: Consider Updating Your Software
- Item 15: Consult Third-Party Source Code for Insights on Its Use
- Item 16: Use Specialized Monitoring and Test Equipment
- Item 17: Increase the Prominence of a Failure's Effects
- Item 18: Enable the Debugging of Unwieldy Systems from Your Desk
- Item 19: Automate Debugging Tasks
- Item 20: Houseclean Before and After Debugging
- Item 21: Fix All Instances of a Problem Class
This chapter is from the book
This chapter is from the book
This chapter is from the book
Item 20: Houseclean Before and After Debugging
Ten possible faults in the software you’re debugging can manifest themselves in a thousand (210) possible combinations. Twenty in a million (220) combinations. Therefore, when you’re debugging, consider picking first the low-hanging fruit around the area you’re working on. These include the following:
Issues that tools can find for you (see Item 51: “Use Static Program Analysis”)
Warnings, such as recoverable assertion failures, that the program produces at runtime
Unreadable code associated with your issue (see Item 48: “Improve the Suspect Code’s Readability and Structure”)
Questionable code identified by comments marked with XXX, FIXME, TODO, or containing cop-out words, such as should, think, must
Other known minor bugs that lie neglected
Debugging a tricky problem without a relatively fault-free environment can mean death from a thousand cuts.
There are counter-arguments to this approach. First, there’s the saying “If it ain’t broke, don’t fix it.” Then comes the question of stylistic inconsistencies that will crop up when you upgrade only part of a system’s code to use more modern facilities. You have to use your judgment here. If you can see that cleaning the code will definitely help you debug an elusive bug, then you may decide to take the risk. If, on the other hand, you’re dealing with fragile code and a bug that you can pinpoint by examining, say, log files, then a code cleanup exercise is probably an unnecessary risk.
After you have located and fixed a fault, you’re not done. Two tasks remain. First, search through the code for other similar errors and fix them (see Item 21: “Fix All Instances of a Problem Class”). Second, deal with code changes you made to pinpoint the problem (see Item 40: “Add Debugging Functionality”). Undo any temporary modifications you added to make the fault stand out. This should be easy if you were working on a separate local revision control branch (see Item 26: “Hunt the Causes and History of Bugs with the Revision Control System”). Also clean up and permanently commit other changes that might be useful in the future, such as assertions, logging statements, and new debug commands.
Things to Remember
Ensure a baseline level of code hygiene before embarking on a major debugging task.
When you finish, clean up temporary code changes and commit useful ones.