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.