Use Assertions Liberally

An assertion is a statement which is thought to be true. Assertions are statements of intent on the part of the programmer which help make the code self-documenting and provide relatively efficient run-time checks that things which the programmer thought were true, actually are true. Using assertions liberally can dramatically improve the quality of your software.

The classic text-book examples are pre-conditions and post-conditions to functions, like that the number passed to a square-root function is positive, and the result is also positive. Rather than putting a comment in listing the pre-conditions to a function, use assertions and treat them as active comments.

Assertions can also be used to check logic deep within complex functions, and with a little extra effort can also be used to check the integrity of complex data structures. The result can be a massive time-saving in otherwise hard-to-find bugs during unit testing, software integration and system testing. Assertions become even more powerful when you have an automated regression test suite.

Never use assertions for error handling. Events such as file opens can fail if the file is missing or the wrong file name is given; these are not appropriate uses of assertions. Also take care to avoid putting side-effects in assertion statements, especially in languages which use macro-processing to remove the assertion code during production builds. Switching assertions off should not affect the behaviour or logic of the application; it should merely improve run-time performance.

Assertions can generally be turned on and off, usually at compile time. Note that assertions reduce the reliability of your code when they are active, because they induce deliberate failures when the statement being asserted turns out not to be true. Assertion statements can contain bugs, and in some cases the overall effect on the application of the assertion being false may have been benign; in either case an artificial failure is induced so it can be picked up during development. Whether to leave assertions active in your product is a policy decision that should be made at the outset; but generally, they get disabled. Customers do not want to see “assert failed” messages, and applications that terminate unexpectedly. Assertions, by their nature, are always unexpected. It's possible that your application will keep running even though the assertion turns out not to be true, and that's generally better than just bombing out. However, the user may get the wrong answer, and in some mission-critical fields that is unacceptable.

Don't get in the habit of ignoring assertions, or just disabling them when they fail. I have had an engineer tell me not to use the “debug” version of a module that I was trying to find an obscure bug in, because the team knew that it “regularly threw assertions”. That's like waving a rag to a bull when I'm bug-hunting; first thing I did was deliberately ignore their advice and run the debug version. Predictably, it thew an assertion straight away, which led me directly to the problem that had been affecting customers and could easily have been found and fixed before the product went out the door. Another point to note is that assertions in one module often get triggered if the module is being mis-used by another module, so debugging should be done with assertions enabled in all modules, not just the one that the engineer is currently focusing on.

---

Social Bookmark this page: