Defensive Programming

One common thread that runs through my coding is defensive programming. About 5%-15% of my code is extra code that I write to check for internal consistency and for debug support.

First of all, any place I make an assumption, I will add a check for it. I check for:

What this buys me is that, for a large class of bugs, the program fails fairly close to the position of the bug. Ideally the program should fail within a few lines of the bug.

Consider the following scenario: assume the difference between having the program fail "very close" to the bug source and "near" the bug source is that it may take, say 10 runs, to isolate the bug for the "near" case versus, say 2 runs, for the &very close". Is this a big deal?

Well, for the some of the programs I work with, some bugs show up only in runs lasting for hours. If we have to run the program 2 times instead of 10 times to isolate the bug, we have saved day(s) in tracking down the bug. Now, keep in mind also that: