Principles Wiki

User Tools

Site Tools

You are here: Principles Wiki » Principles » Murphy's Law (ML)
principles:murphy_s_law

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
principles:murphy_s_law [2020-10-12 12:41] – old revision restored (2013-03-19 16:58) 159.69.186.191principles:murphy_s_law [2020-10-12 12:41] – old revision restored (2013-02-12 13:34) 159.69.186.191
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't Repeat Yourself|DRY]])+  * Avoid duplication and manual tasks, so necessary changes are not forgotten (see [[Don't Repeat Yourself]])
   * 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]])+
   * ...   * ...
- 
- 
-===== Caveats ===== 
- 
-See section [[#contrary principles]]. 
  
  
Line 83: 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 "fool-proof" so usage and maintenance mistakes are prevented. In this aspect KISS is rather a contrary principle. Both applies at the same time so a tradeoff has to be made whether correct implementation or correct usage and maintenance are more important in the given case. This means, it is necessary to consider KISS in addition to ML in order to find a suitable compromise. See [[#example 1: parameters]].+  * **[[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 "fool-proof" so usage and maintenance mistakes are prevented. In this aspect KISS is rather a contrary principle. Both applies at the same time so a tradeoff has to be made whether correct implementation or correct usage and maintenance are more important in the given case. This means, it is necessary to consider KISS in addition to ML in order to find a suitable compromise.
  
 ==== Complementary Principles ==== ==== Complementary Principles ====
Line 95: Line 89:
  
  
-===== Examples =====+===== Example =====
  
 ==== Example 1: Parameters ==== ==== Example 1: Parameters ====
Line 103: 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, String replacement) +replaceFirst(String pattern, string replacement) 
-replaceAll(String replacement, String pattern)+replaceAll(String replacement, string pattern)
 </code> </code>
 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 110: 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, String replacement) +replaceFirst(String pattern, string replacement) 
-replaceAll(String pattern, String replacement)+replaceAll(String pattern, string replacement)
 </code> </code>
 This is less error prone. When for example a call to ''replaceFirst()'' is replaced by a call to ''replaceAll()'', one cannot forget to exchange the parameters anymore. This is how is is done in the [[http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#replaceFirst(java.lang.String, java.lang.String)|Java API]]. This is less error prone. When for example a call to ''replaceFirst()'' is replaced by a call to ''replaceAll()'', one cannot forget to exchange the parameters anymore. This is how is is done in the [[http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#replaceFirst(java.lang.String, java.lang.String)|Java API]].
Line 117: 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 "natural", such a mistake is still possible. An alternative would be the following: 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 "natural", such a mistake is still possible. An alternative would be the following:
 <code java> <code java>
-replaceFirst(Pattern pattern, String replacement) +replaceFirst(Pattern pattern, string replacement) 
-replaceAll(Pattern pattern, String replacement)+replaceAll(Pattern pattern, string replacement)
 </code> </code>
 Here both methods expect a ''Pattern'' object instead of a regular expression expressed in a string. Mixing up the parameters is impossible in this case as the compiler would report that error. On the other hand using these methods becomes a bit more complicated:  Here both methods expect a ''Pattern'' object instead of a regular expression expressed in a string. Mixing up the parameters is impossible in this case as the compiler would report that error. On the other hand using these methods becomes a bit more complicated: 
principles/murphy_s_law.txt · Last modified: 2021-10-20 21:18 by christian