How to use a debugger as a bug preventive tool

12/17/2009 3:47 AM EST

I agree it us a new perspective. It is not always feasible esp if the code is huge.

However, Unit Testing is a repeatable process, and test coverage should be decent. We can't keep doing this everytime code changes.

12/17/2009 10:17 AM EST

This is a good practice, developers do this from time to time when they don't yet have a feel/confidence of whether the newly created software is actually doing what it is supposed to do and is to make sure it is not somehow magically producing the limited test run result and as the author correctly points out, this is best done earlier than later. A good programmer will not attempt to run the code until he is mostly confident that it will run successfully but when he does run the code after such level of comfort, he will be the most skeptical. It is difficult to switch between these opposing roles and in the latter part, using the techniques mentioned in the article comes handy. It is more suitable in a bottom-up development style i.e first on little pieces of software so you know the building blocks are solid before you put them together to build higher levels of software, but as correctly pointed, is not a substitute for repeatable unit testing (which can come after this step because comprehensive unit tests also take a good amount of time). Good tools also have code coverage (so you know if your unit test didn't cover some code), run-time uninitialized memory read detection, run-time out of bounds access detection etc (there are also static analysis tools that detect statically detectable problems before even you run the code). Asserts and tracing variables/signals in the code also help to see if assumptions and intermediate quantities are valid. No one tool is a winner over others, all tools are available to the developer to use when it makes sense during software creation and repair to be productive and effective, the more variety the better (even if some features are used very rarely, because they are useful when they do need to be used). Tools need to keep evolving to meet needs such as multi-core debug, advanced tracing and visualization etc and future tools may also have touch screen UI enhancements for more intuitive debug.

12/18/2009 9:40 AM EST

Huh... doesn't everyone do this? Are you saying there are programmers who are just writing all their code in a flurry of keystrokes and then press run and hope it works? I don't think I've ever seen anyone do that. Fresh rookies still in school maybe, but none who has gone through a comp. sci degree, let alone hardened veteran programmers with years of experience.

12/21/2009 9:33 AM EST

Nathan, a big fat AMEN! to everything you have written here. I use this technique to give me confidence that what I wrote is really what I meant.

Lundin, you better believe the *majority* of programmers just hit the button, and if the final number is good, ship it. For these people, their testing is never more than a form of black box testing. Drives me crazy!

Using a debugger helps me get into the mind of the program (if that makes sense). As I go past a particular point in the code, I have everything I need to be able to audit that code's interaction with the rest of the system.

I put a breakpoint on every major calculation, and every branch point. For new code, that may mean hundreds of breakpoints. As Nathan writes, I then run the code every which way, clearing breakpoints if the code passes my beady-eyed review, until there aren't any breakpoints left. It's like an interactive coverage tool.

piyush_ likes unit tests. I like to do unit tests too, but the payoff for unit tests comes later, whereas the payoff for using a debugger to do your "live desk check" pays off immediately. Both are complementary and valuable.

One major requirement that Nathan omitted is that your platform can support having enough breakpoints to cover the code to the density you need. It continually drives me crazy that the Atmel CPUs I use only support 3 breakpoints.

A minor requirement is to have a stable platform! It's very frustrating if your debugger crashes, or there's a problem with debugging support on your platform, and you lose the 180 breakpoints you haven't cleared yet. Without stability, the value of this technique is greatly diminished.

In general, a fine article. Why don't they teach techniques like this at University?

12/21/2009 4:36 PM EST

how is this related to opensource software ? Is Multi Debugger opensource ? It shouldn't have opensource in the url.

12/22/2009 3:48 AM EST

During a typical SW build-test-release process, I do put quite a few printfs to see the program flow and inspect state variables. It is not a single print towards the end that determines a pass-fail criteria. In other words, unit tests are not black-box, they do also inspect the internal states and check if they are as expected.

I would rather prefer using printf, than stepping in a debugger - gives the same information and easier to automate.

1/7/2010 1:23 PM EST

Caution to KarthickG: be very careful using printf in a real-time system. It will mess up the normal timing. It may hide or create race conditions.

1/8/2010 1:42 PM EST

It is scary to think that programmers wouldn't use a debugger regularly. However, I am sure they do just that - I have seen posts in several online "help" forums in which it is apparent the people needing help have NEVER used a debugger.

All the "quality control" or "process improvement" or "code/peer review" in the world won't replace the original authors doing their own debugging.