Offensive programming
Offensive programming is a name used for the branch of defensive programming that expressly departs from defensive principles when dealing with errors resulting from software bugs. Although the name is a reaction to extreme interpretations of defensive programming, the two are not fundamentally in conflict. Rather, offensive programming adds an explicit priority of not tolerating errors in wrong places: the point where it departs from extreme interpretations of defensive programming is in preferring the presence of errors from within the program's line of defense to be blatantly obvious over the hypothetical safety benefit of tolerating them. This preference is also what justifies using assertions.
Distinguishing errors
The premise for offensive programming is to distinguish between expectable errors, coming from outside the program's line of defense, however improbable, versus preventable internal errors that shall not happen if all its software components behave as expected.Contrasting examples:
| Expectable errors | Preventable errors |
| Invalid user input | Invalid function arguments |
| Depletion of OS resources | Value out of defined range |
| Hardware failure | Undocumented return value or exception |
Bug detection strategies
Offensive programming is concerned with failing, so to disprove the programmer's assumptions. Producing an error message may be a secondary goal.Strategies:
- No unnecessary checks: Trusting that other software components behave as specified, so to not paper over any unknown problem, is the basic principle. In particular, some errors may already be guaranteed to crash the program, for example dereferencing a null pointer. As such, null pointer checks are unnecessary for the purpose of stopping the program.
- 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 and fallback data : These can hide defects in the main implementation, or, from the user point of view, hide the fact that the software is working suboptimally. Special attention to unimplemented parts may be needed as part of factory acceptance testing, as yet unimplemented code is at no stage of test driven development discoverable by failing unit tests.
- Remove shortcut code : 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.