Design by Contract
Every invocation of a function or object is saddled with baggage — assumptions we make about arguments and the state of the system. If a called function assumes interrupts are off, but they’re not, for example, clearly bad things will happen.
Design by contract (DBC) requires that we explicitly specify these assumptions; the compiler generates additional code to check them at runtime. That immediately rules the technique out for small, resource-constrained systems. This paper provides an overview of DBC’s benefits, which are substantial. They include: more reliable code, since arguments and assumptions are clearly specified in writing; greater ease in reusing code; greater ease in writing tests, since the contracts specify boundary conditions; clearer function designs; easier debugging; and easier maintenance.
In software engineering, a single bit error can cause the system to completely fail. DBC is like adding fuses to the code. The system is going to crash; it is better to let it happen early on and seed debugging breadcrumbs than fail to in a manner that no one can subsequently understand.
Please disable any pop-up blockers for proper viewing of this Whitepaper.