Defensive Programming states that no one should be trusted in the development even yourself. It is to ensure the low number of bugs, high comprehensibility of the codebase and predictable software output even there are unexpected inputs or user actions.
There are several mechanisms that aid in Defensive Programming:
If, for example, you have stumbling across the application codebase, run it, and found something that surprise you, reevaluate your assumptions, be willing to debug it#. Don’t just “know” your code works, prove it, in this context, with this data, with these boundary conditions. Add new test# to it, Crash Program Earlier# or put some Assertions#. You can go further by adopting Defensive Programming#, enforcing checks on precondition, postcondition and class invariant by Design by Contract (DBC)#.
DBC is a software engineering practice typically used in #202202041514 and #202207072153 that treat module design as designing a contract. The contract consists of three major conditions: precondition, postcondition and class invariant.