Previous section   Next section

Imperfect C++ Practical Solutions for Real-Life Programming
By Matthew Wilson
Table of Contents
Chapter 1.  Enforcing Design: Constraints, Contracts, and Assertions


1.1. Eggs and Ham

I'm no doubt teaching all you gentle readers about egg-sucking here, but it's an important thing to state nevertheless. Permit me to wax awhile:

  • It's better to catch a bug at design time than at coding/compile time.[1]

    [1] I'm not a waterfaller, so coding time and compiling time are the same time for me. But even though I like unit-tests and have had some blisteringly fast pair-programming partnerships, I don't think I'm an XP-er [Beck2000] either.

  • It's better to catch a bug at coding/compile time than during unit testing.[2]

    [2] This assumes you do unit testing. If you don't, then you need to start doing so, right away!

  • It's better to catch a bug during unit testing than during debug system testing.

  • It's better to catch a bug during debug system than in prerelease/beta system testing.

  • It's better to catch a bug during prerelease/beta system testing than have your customer catch one.

  • It's better to have your customer catch a bug (in a reasonably sophisticated/graceful manner) than to have no customers.

This is all pretty obvious stuff, although customers would probably disagree with the last one; best keep that one to ourselves.

There are two ways in which such enforcements can take effect: at compile time and at run time, and these form the substance of this chapter.


      Previous section   Next section