But a debugger is as good as the programmer that uses it: if you are not skilled in using it, it's not worth the cost. A debugger is your first line in finding and fixing bugs. Here are other tips I've relied on over the years:
- Know your IDE's debugger limitations and features, and how to run it well. Only then can it be reliable and feasible.
- The obvious places may not be the culprits! After developing for a while, you start building a mental list of possible failure points and such, and develop a tendency of focusing too much on those areas when bugs do manifest themselves. Throw that mentality out and analyze issues from a "big picture" standpoint.
- Revert to the last working code and increment towards the the failure until you may find which additions cause the bug to happen. To this, you need a good versioning system. I've used Subversion, CVS, and Superversion - all free, of course.
- If there is a chunk of code causing the problem, contain the bug by using try/catch statements around it, and get a full error log. Then start walking that chunk, checking whether expected values are being set properly, and what is missing-in-action.
- Befriend the specification documents for insight. If you've debugged programs that use Windows system calls alot, you obviously don't have Windows source code to walk through, so MSDN (as scant as it is) will help some. Knowing what the WinAPI expects will help. Language forums are great help - chances are that you ain't the first person seeing this.
- Learn to read memory dumps, especially if you write C/C++ programs, or have to use JNI. Java hides these details from you, but Java debuggers should allow you to review entire data structures.
- Walk away from the code - take a hike, sleep, talk to your dog - whatever you do to take your mind off the issue. You won't believe how many times I've returned to the code and seen the problem right away - and felt so dumb.
- The blame game should start from inside out - first yourself, then the design, then the compiler, then the OS, and if you want - the language.
- Rewrite the offending chunk of code, perhaps using a different technique or even technology. Sometimes to understand C program issues, I've re-written chunks in Java and analyzed them from that standpoint. If you've fixed the same section nearly 5 times, it's time to re-write that piece afresh.
- Output messages - usually the first thing everyone does. I'm moving away from this - one of the 9 steps above will get me to the bug much faster.
