Aktuelle Änderungen Printable View Änderungen Bearbeiten
DataAbstraction > DataBinding > DataCleaning > DataCrunching > DataDriven > DataDrivenProgramming > DataSets > DataSet > DatabaseDesign > DatabaseGlossary > DatabaseManagementSystems > DBMS > DatabasesWithClojure > DeBugging > DebugJavaApplications > DebuggingPHP > DefensiveProgrammingClear TrailThe idea behind DefensiveProgramming is that you should expect erroneous input to your functions.[1]
Defensive programming is NOT coding so that unexpected conditions cause immediate failure, but rather, coding so that the program won't abort, regardless of how bad the conditions are. As such, it is a reasonable idea for production code, but a bad idea for pre-production code. [...] it hides bugs! [2]
My definition of DefensiveProgramming in DesignByContract terms: Defensive programming is attempting to fulfill the contract even when preconditions have failed.
Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software in spite of unforeseeable usage of said software. The idea can be viewed as reducing or eliminating the prospect of Murphy's Law having effect. Defensive programming techniques come into their own when a piece of software could be misused mischievously or inadvertently to catastrophic effect.
Preconditions, postconditions and invariants validation are also part of defensive programming.