Best practices for debugging

Question

I've been doing quite a bit of debugging of managed applications lately using both Visual Studio and WinDbg, and as such I'm often ask to assist colleagues in debugging situations. On several occasions I have found people aho just insert break points here and there and hope for the best. In my experience that is rarely a useful technique.

My approach goes something like this.

• Reproduce the problem. Ideally reduce the input as much as possible.

• Examine what goes wrong and list theories for where the bug may be.

• Examine one theory at a time by debugging that specific area of the code.

Repeat steps as necessary.

For complex debugging problems I often work with a colleague. For WinDbg this is especially useful.

Any other useful tips or best practices for debugging?

Answer 1

If there was one tip I could give to everyone about debugging it would be to break it again.

That is, when you think you've found the fix and the system seems to work. Back the fix out and see if the system breaks again.

Sometimes you can get lost in the sequence of what you've tried as potential solutions and you finish up in a totally different area of the system while you're debugging the problem. Then you forget what you've changed back in the original area where you were working.

Backing the fix out and then reproducing the problem ensures that the candidate fix isn't relying on something else that you've changed in another part of the system. That your patch for the fix is a correct standalone solution.

HTH.

cheers,

Rob

Answer 2

Not directly related to debugging, but to make debugging easier in the future, there are a few things to consider:

• Implementing unit testing, preferably in the form of TDD, forces you to stay on task and develop only with the goal of passing tests. It is harder to "wander" when you are coding to a test, instead of to a task.
• Get in the practice of regularly refactoring your code. Small, on-point methods are easier to debug than monolithic "jack of all trades" methods.
• Utilize your team members. Often adding an extra set of eyes can help flush something out. Chances are, if you do not find something in a relatively quick manner, you are going to continue to overlook it for a while.
• You can always rollback code in your version control system to try and isolate what version of a file caused the introduction of the bug. Once you do that, you can diff between the last good and first bad and just focus on the changes between the two.