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 [2020-10-12 12:40] – old revision restored (2013-03-19 17:49) 159.69.186.191 | principles:murphy_s_law [2020-10-12 12:41] – old revision restored (2013-02-12 13:34) 159.69.186.191 | ||
---|---|---|---|
Line 34: | Line 34: | ||
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 40: | ||
* 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|KISS]]) | + | * Make the design simple, so there will be fewer implementation defects (see [[Keep It Simple Stupid]]) |
* 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|UP]]) | + | * Use the same mechanisms wherever reasonably possible (see [[Uniformity Principle]]) |
- | * Use consistent naming and models throughout the design (see [[Model Principle|MP]]) | + | * Use consistent naming and models throughout the design (see [[Model Principle]]) |
- | * Avoid Preconditions and Invariants (see [[Invariant Avoidance Principle|IAP]]) | + | |
- | * Use assertions to detect problems early. | + | |
* ... | * ... | ||
- | |||
- | |||
- | ===== Caveats ===== | ||
- | |||
- | See section [[#contrary principles]]. | ||
Line 84: | Line 77: | ||
==== 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 96: | Line 89: | ||
- | ===== Examples | + | ===== Example |
==== Example 1: Parameters ==== | ==== Example 1: Parameters ==== | ||
Line 104: | Line 97: | ||
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 111: | Line 104: | ||
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 118: | Line 111: | ||
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 '' |
principles/murphy_s_law.txt · Last modified: 2021-10-20 21:18 by christian