How to improve your ability to debug existing code

Question

A common task in the working world is dealing with existing, but buggy code. What are some tips to improve your skills as a debugger?

Answer 1

Don't Assume Anything

It's often tempting to just say "oh, I know what this bit of code is doing, it's fine". Don't do that. Test every assumption and step through everything carefully.

Answer 2

Testing incrementally.

Go depth first in your code and test it from smallest module moving up gradually.In this way, you are not under too much stress trying to figure out where the problem exactly might be.

It also means that it affects less code at a time since you are moving incrementally..as at times I have had issues where I fixed something and that lead to breaking lots of other stuff. I give credit to my boss for this as he taught me this when I messed around.

Answer 3

Divide and conquer is a good approach. Try to identify some visible input (user input/network event ...) and output (log, output to user, outbound network message ...) between which the issue exists. Try putting prints at sizable chunks or significant points between them and try to narrow down where the bug is in the code.

Divide and conquer can also work very well in case of regressions over version controlled code. Find two builds - one where it works as expected, other with the regression. Narrow the gap down till you are left with a bunch of checkins as potential suspects.

Answer 4

Rather than the binary bug chop, write tests in the form

• Given...
• When...
• Expect...

To verify what you actually know to be true about the functioning of the app versus what you assume to be true.

Most IDEs make it easy to extract methods and to generate xUnit testing stubs. Make use of that.

Why not sprinkle debugs? Because after you are done, you will likely have to undo much of that work and delete a fair amount of those debugs. When you write tests, your debugging will aid in the prevention and detection of future bugs.

Answer 5

Keep debugging. If you debug a lot, you'll improve.

Answer 6

As others have said - do not assume anything. This is especially true if its code you've written. When debugging others code you are more likely to slow down because the code is new to you or you don't trust the coder. When debugging your own code its too easy to assume you wrote it correctly, slow down!

For the actual process of debugging:

• Write unit tests if they don't already exists.
• Add appropriate logging if doesn't already exist.
• Then use the debugging.

Adding the unit tests and logging first more efficient that using the debugger first up. You also get the added advantage of having the unit tests to help not introducing future bugs and the logging will help debugging sessions in the future.

Answer 7

Before stepping over a small chunk of code, see if you can accurately determine the outcome. This does tend to fly in the face of don't assume anything (which I up voted BTW) but as you gain experience, it can help narrow down where to look.

This may sound trivial, but learn the nuances of your debugger and learn the hot-keys. Sometimes debuggers can be slow enough that your mind wonders when your stepping through. If you can keep up with the machine and aren't mousing around, that can help.

If you can modify code while debugging:

• consider asserting pre AND post conditions. Sometimes you can then step over, instead of into code.
• for if statements with complicated expressions, consider something (some may frown at this but it works for me)

like:

bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
   // more code here
}

instead of:

if ( a < 5 || a > 10 )
{
   // more code here
}

For the cases you can't debug everything, for whatever reason, learn to "rubber-duck" with a co-worker. Sometimes the act of explaining sheds light. (ok, maybe this isn't exactly in the questions theme, but I think it's close enough to warrant mention)

Answer 8

Two things, based on spending most of the last 22 years maintaining code other people wrote.

Understand the kinds of bugs you tend to write.

For instance, I'm a very meticulous coder, so once my code compiles, it's usually free of trivial bugs. So my bugs tend to be weird complicated things like thread deadlocks. On the flip side, I have friend who mostly writes trivial bugs - semicolons at the end of C++ for loops, so the next line only gets executed once, that kind of thing.

Don't assume other people write the same kinds of bugs you do.

I don't know how many times I've wasted time pulling out the big debugging guns, assuming a bug was my kind of really subtle weird thing, only to have my friend look over my shoulder and go, "Did you notice that extra semicolon?" After years of that, I first go for the trivial, low-hanging fruit when looking at other peoples' code.

Answer 9

Know your tools. For example, Visual Studio's debugger has an awesome feature called TracePoints that are like breakpoints but instead of stopping your code instead inserts a trace statement into the debug output.

Reading books or taking a class on how to use your debugger is highly recommended. I took a couple of classes and read a few books by John Robbins that made a big difference in my effectiveness as a debugger.

Answer 10

Understand functionally what the code is trying to do. If you don't know the complete picture (all test cases this code must pass) it's hard to debug properly without introducing new bugs

Answer 11

Write automated unit test and other types of integration and functional tests.

The more automated tests you have, the less time you need to spend in a debugger.

Also, good design - SOLID principles. If you're writing small, focused classes and favoring composition over inheritance, eliminating duplication, etc., then your code will always be easier to debug.

I find that well designed code produces a different set of bugs that code that is not designed well. Generally speaking, well-designed code produces bugs that are easier to find, reproduce, and fix.

The exception (and there always is one) is multithreading code :-)

Answer 12

If you've narrowed it down to a small region, but can't still can't spot the error, try the 'view code + assembly' option of your debugger. Knowing enough ASM to say "there should be a branch here" or "why is it only copying the low word?" will often pinpoint the coding error.

Answer 13

Check out the very valuable book Why Programs Fail: A Guide to Systematic Debugging, by Andreas Zeller. It will introduce you to many techniques, theories, and tools, some of which are on the cutting edge of research.

The slides for the book are available online, but I find the book itself is easier to read.

The book will help get you started and make you think more scientifically about debugging, but it's no substitute for practice. You may need to be writing and debugging for 10 years before you see an order of magnitude improvement in your performance. I still remember having my jaw drop at Sun seeing senior developers, who have been programming for Unix for 30 years, find obscure multithreading or parallel bugs in minutes. Experience matters!