97 Things Every Programmer Should Know

Chapter 9. Check Your Code First Before Looking to Blame Others

Allan Kelly

DEVELOPERS—ALL OF US!— often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that’s broken.

Yet, in truth, it is very (very) unusual that code is broken by a bug in the compiler, interpreter, OS, app server, database, memory manager, or any other piece of system software. Yes, these bugs exist, but they are far less common than we might like to believe.

I once had a genuine problem with a compiler bug optimizing away a loop variable, but I have imagined my compiler or OS had a bug many more times. I have wasted a lot of my time, support time, and management time in the process, only to feel a little foolish each time it turned out to be my mistake after all.

Assuming that the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality. Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, open source software, there may be good reason to suspect the software. (Equally, an alpha version of commercial software might be suspect.)

Given how rare compiler bugs are, you are far better putting your time and energy into finding the error in your code than into proving that the compiler is wrong. All the usual debugging ...