principles:murphy_s_law
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
principles:murphy_s_law [2021-09-02 10:43] – old revision restored (2021-05-11 22:12) 65.21.179.175 | principles:murphy_s_law [2021-09-02 10:44] – old revision restored (2021-05-11 22:11) 65.21.179.175 | ||
---|---|---|---|
Line 3: | Line 3: | ||
===== Variants and Alternative Names ===== | ===== Variants and Alternative Names ===== | ||
- | * Design for Errors((Alan M. Davis: //201 Principles | + | * Design for Errors(({{page> |
===== Context ===== | ===== Context ===== | ||
/* fill in contexts here: */ | /* fill in contexts here: */ | ||
* [[contexts: | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
===== Principle Statement ===== | ===== Principle Statement ===== | ||
Line 25: | Line 27: | ||
There are different kinds of possible errors that can and according to ML eventually will occur in some way: Replicated data can get out of sync, invariants can be broken, preconditions can be violated, interfaces can be misunderstood, | There are different kinds of possible errors that can and according to ML eventually will occur in some way: Replicated data can get out of sync, invariants can be broken, preconditions can be violated, interfaces can be misunderstood, | ||
- | Note that Murphy' | + | Note that Murphy' |
Line 34: | Line 36: | ||
This means the fewer possibilities there are that a mistake is made, the fewer there will be. As mistakes are generally undesirable, | This means the fewer possibilities there are that a mistake is made, the fewer there will be. As mistakes are generally undesirable, | ||
+ | Note that ML does //not// claim that everything constantly fails unless there is no possibility to do so. It simply says that statistically in the long run a system will fail if it can. | ||
===== Strategies ===== | ===== Strategies ===== | ||
Line 40: | Line 42: | ||
* Make use of static typing, so the compiler will report faults | * Make use of static typing, so the compiler will report faults | ||
- | * Make the design simple, so there will be fewer implementation defects (see [[Keep It Simple Stupid]]) | + | * Make the design simple, so there will be fewer implementation defects (see [[Keep It Simple Stupid|KISS]]) |
* Use automatic testing to find defects | * Use automatic testing to find defects | ||
- | * Avoid duplication and manual tasks, so necessary changes are not forgotten (see [[Don' | + | * Avoid duplication and manual tasks, so necessary changes are not forgotten (see [[Don' |
* Use polymorphism instead of repeated switch statements | * Use polymorphism instead of repeated switch statements | ||
- | * Use the same mechanisms wherever reasonably possible (see [[Uniformity Principle]]) | + | * Use the same mechanisms wherever reasonably possible (see [[Uniformity Principle|UP]]) |
- | * Use consistent naming and models throughout the design (see [[Model Principle]]) | + | * Use consistent naming and models throughout the design (see [[Model Principle|MP]]) |
+ | * Avoid Preconditions and Invariants (see [[Invariant Avoidance Principle|IAP]]) | ||
+ | * Use assertions to detect problems early. | ||
* ... | * ... | ||
+ | |||
+ | |||
+ | ===== Caveats ===== | ||
+ | |||
+ | See section [[#contrary principles]]. | ||
Line 63: | Line 72: | ||
/* * [[wiki: | /* * [[wiki: | ||
+ | Furthermore every defect in any system is a manifestation of ML. If there is a fault then obviously something went wrong. The correlation between the number of possibilities for introducing defects and the actual defect count can be regarded trivially intuitive. | ||
===== Relations to Other Principles ===== | ===== Relations to Other Principles ===== | ||
Line 77: | Line 86: | ||
==== Contrary Principles ==== | ==== Contrary Principles ==== | ||
- | * **[[Keep It Simple Stupid]] (KISS)**: On the one hand a simpler design is less prone to implementation errors. In this aspect KISS is similar to ML. On the other hand it is sometimes more complicated to make a design " | + | * **[[Keep It Simple Stupid]] (KISS)**: On the one hand a simpler design is less prone to implementation errors. In this aspect KISS is similar to ML. On the other hand it is sometimes more complicated to make a design " |
==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
Line 89: | Line 98: | ||
- | ===== Example | + | ===== Examples |
==== Example 1: Parameters ==== | ==== Example 1: Parameters ==== | ||
Line 97: | Line 106: | ||
The following method signatures are a bad choice: | The following method signatures are a bad choice: | ||
<code java> | <code java> | ||
- | replaceFirst(String pattern, | + | replaceFirst(String pattern, |
- | replaceAll(String replacement, | + | replaceAll(String replacement, |
</ | </ | ||
Eventually someone will mix up the order of the parameters leading to a fault in the software which is not detectable by the compiler. | Eventually someone will mix up the order of the parameters leading to a fault in the software which is not detectable by the compiler. | ||
Line 104: | Line 113: | ||
So it is better to make parameter lists consistent: | So it is better to make parameter lists consistent: | ||
<code java> | <code java> | ||
- | replaceFirst(String pattern, | + | replaceFirst(String pattern, |
- | replaceAll(String pattern, | + | replaceAll(String pattern, |
</ | </ | ||
This is less error prone. When for example a call to '' | This is less error prone. When for example a call to '' | ||
Line 111: | Line 120: | ||
But here still one could mix up the two string parameters. Although this is less likely, as having the substring to look for first is " | But here still one could mix up the two string parameters. Although this is less likely, as having the substring to look for first is " | ||
<code java> | <code java> | ||
- | replaceFirst(Pattern pattern, | + | replaceFirst(Pattern pattern, |
- | replaceAll(Pattern pattern, | + | replaceAll(Pattern pattern, |
</ | </ | ||
Here both methods expect a '' | Here both methods expect a '' | ||
Line 154: | Line 163: | ||
<code java> | <code java> | ||
- | Date date1 = new Date(2013, 01, 16); | + | Date date1 = new Date(2013, 01, 12); |
Date date2 = date1; | Date date2 = date1; | ||
- | System.out.println(date1); | + | System.out.println(date1); |
- | System.out.println(date2); | + | System.out.println(date2); |
date1.setMonth(2); | date1.setMonth(2); | ||
- | System.out.println(date1); | + | System.out.println(date1); |
- | System.out.println(date2); | + | System.out.println(date2); |
</ | </ | ||
- | Furthermore as can be seen in the code above, the month value counterintuitively is zero-based, which results in 1 meaning February. This obviously is another source for mistakes. | + | Furthermore as can be seen in the code above, the month value counterintuitively is zero-based, which results in 1 meaning February. This obviously is another source for mistakes. Also the order of the parameters can be mixed up easily. And lastly this does not refer to a date in 2013 but to one in 3913! The year value is meant to be " |
Because of these and several other flaws in the design of the Java date API, most of the methods in '' | Because of these and several other flaws in the design of the Java date API, most of the methods in '' | ||
Line 179: | Line 188: | ||
* [[wiki> | * [[wiki> | ||
+ | ===== Discussion ===== | ||
+ | |||
+ | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/murphy_s_law.txt · Last modified: 2021-10-20 21:18 by christian