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 (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, 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 (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 (limp mode) and fallback data (default values): 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 (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

• Fail-fast system