#if Programmer Is Forgetful

Here’s a trick that I use quite a lot…

#if DEBUG
    DumpCallStack();
#else
    #error REMOVE BEFORE RELEASE - Tom added this looking for bug 1223
#endif

Why on earth would anyone want to do that? Well sometimes when you’re looking for a bug you add either debugging code or experimental code that you think might fix the issue. This code is often not of production quality. Then you find the actual bug and it’s nowhere near the new code, or you have to go off and do something else. You then forget about the code that you’ve added, it gets checked in and eventually makes it out into a release. Then you end up with Ariane 5 when it hits the customer site…

So why not just wrap it in #if DEBUG?

There are 2 reasons;

1. Because over time you end up with a hell of a lot of #if DEBUG and your actual code gets difficult to read.
2. More importantly because your debug version starts to radically depart from the release version. Consider the above – generating a stack trace is a relatively expensive operation and ultimately this writes it to a file. This quite substantially alters the way the timings in the code and the write to file has some (limited) synchronisation effects. This could actually mask problems.

Ultimately the more similar the debug version is to the release version the maintainable the code is and the more chance there is of a problem being spotted before the code gets to the customer. Experimental code and any form of debug code that could cause the debug version to function significantly differently to the release version should be removed.