1 Programming styles
General reference might be found on wikiwand.
1.1 Defensive programming style
Defensive programming style consist of implementation of many controls at the entry of functions. This is required to ensure parameters meet some conditions required by the developer or the context.
There are some benefits to this style. It is clearly incremental, and you can always add as many controls as desired, to meet the level of robustness and reliability you aim for. Indeed, this comes with some drawbacks that are repeated verifications at various depth levels, and worst the executed verifications are often the same code, leading to a waste of time during implementation, testing and execution.
Second, an evolution of any function signature in the function call chain, may imply shallow or deep changes in the subsequent verifications, depending of the case.
Defensive programming style also requires a good documentation, as there is no way to infer rationally and with a high level of confidence, what type has to be used for a given parameter of a function.
Notice, that quality and consistency of type and value verification changes from one package to another.
1.2 Offensive programming style
Offensive programming styles works differently. It is based on an implicit contract with bilateral responsibilities
- developer implements required verification about values, not about types unless absolutely required,
- end-user provides values with right or wrong types, when using developer delivered package
- type checks can be enforced at any time by end-user if needed. They are not hard coded by the developer in each function.
In this way, the contract, is end-user is responsible of type concordance and developer is responsible of implementation from type concordance. Instrumentation is provided to let the end-user easily check the type concordance.