Excel 2003 VBA Programmer's Reference

8

Debugging and Testing

There are hundreds of books on programming. Interestingly, only a relatively small percentage of those books are either specifically about debugging and testing or contain chapters dedicated to it. The interesting aspect is that many reports (and our experience) suggest that more than half of a programmer's time will be spent debugging code. Given these proportions, one might think there should be a greater number of books about debugging and testing and what not to write than there would be books predominantly about code.

There are a few basic guidelines for writing bulletproof code. The first rule is if you don't write it then you won't need to test it; or, less is more. The second is that you will spend more time “fixing” what you write than “writing” what you'll fix. The third is instrument your code—add self-diagnosing code—when you initially write lines of code because you will have more ideas about the assumptions that are being made as you write than you will six months later. (By this time it's more than likely someone else will be struggling with your code, and you'll be on to something new. Sounds good, but that something new may be code someone else wrote that wasn't instrumented either.)

Being adept at finding bugs introduced by you or, more importantly, others, is an art form, like playing an instrument, or flying airplanes. Some are mechanically proficient and others demonstrate a certain grace and beauty. (If you have ever spent 30 hours ...