Offensive programming
Offensive programming is a reaction to extreme interpretations of defensive programming. Whereas defensive programming centers around graceful handling of errors in general, the emphasis in offensive programming is to NOT gracefully handle errors that would imply a software bug – prioritizing the detection of bugs over the hypothetical safety benefit of tolerating them.[1][2]
Distinguishing errors
Central to the concept is distinguishing between expectable errors, coming from the program's outside environment, however improbable, versus preventable errors that shall not happen if all software components behave as expected.
Examples:
| Expectable errors | Preventable errors |
|---|---|
| Invalid user input | Invalid function arguments |
| Depletion of OS resources (such as storage, memory) | Value out of defined range (e.g. enum) |
| Hardware failure (such as network, storage) | Undocumented return value or exception |
Bug detection strategies
Offensive programming is concerned with failing, not necessarily producing error messages; that may be a secondary goal.
Strategies:
- No check: Checking that other software components behave as specified is not considered the obligation of the calling code, so checks of this nature can be omitted. In particular, some errors may already be guarranteed to crash the program (depending on programming language or running environment), for example dereferencing a null pointer. As such, null pointer checks are unnecessary for the purpose of stopping the program (but can be used to print error messages).
- Assertions – checks that can be disabled – are the preferred way to check things that should be unnecessary to check, such as design contracts between software components.
- Remove fallback code (aka. limp mode): Limp modes may hide bugs in the main implementation, or, from the user point of view, hide the fact that the software is working suboptimally.
- Remove shortcut code (see the strategy pattern): A simplified code path may hide bugs in a more generic code path if the generic code almost never gets to run. Since the two are supposed to produce the same result, the simplified one can be eliminated.
See also
References
- ^ "Offensive Programming". Cunningham & Cunningham, Inc. Retrieved 4 September 2016.
- ^ Broadwall, Johannes (25 September 2013). "Offensive programming". Thinking Inside a Bigger Box. Retrieved 4 September 2016.