Differences

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

--- principles:murphy_s_law [2021-09-02 10:44] – old revision restored (2021-05-11 22:11) 65.21.179.175
+++ principles:murphy_s_law [2021-09-02 17:57] – old revision restored (2021-05-11 22:11) 65.21.179.175
@@ Line 3: / Line 3: @@
 ===== Variants and Alternative Names =====
-  * Design for Errors((Alan M. Davis: //201 Principles of Software Development//))
+  * Design for Errors(({{page>resources:201 Principles#reference}}))
 ===== Context =====
 /* fill in contexts here: */
   * [[contexts:Object-Oriented Design]]
+  * [[contexts:API Design]]
+  * [[contexts:User Interface Design]]
+  * [[contexts:Implementation]]
 ===== 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, parameters can be given in the wrong order, typos can occur, values can be mixed up, etc.
-Note that Murphy's law also applies to every chunk of code. According to the law the programmer will make mistakes while implementing the system. So it is better to implement a simple design, as this will have fewer possibilities to make implementation mistakes. Furthermore code is maintained. Bugfixes will be necessary present functionality will be changed and enhanced, so every piece of code will potentially be touched in future. So a design is better the fewer possibilities there are to introduce faults while doing maintenance work.
+Note that Murphy's law also applies to every chunk of code. According to the law the programmer will make mistakes while implementing the system. So it is better to implement a simple design, as this will have fewer possibilities to make implementation mistakes. Furthermore code is maintained. Bugfixes will be necessary present functionality will be changed and enhanced, so every piece of code will potentially be touched in the future. So a design is better the fewer possibilities there are to introduce faults while doing maintenance work.
@@ Line 66: / Line 68: @@
 /*  * [[wiki:Examined]]*/
-  * [[wiki:Accepted]] The principle is widely known and it's validity is assumed. Nevertheless sometimes it is rather used as a kind of joke instead of an design advice. See for example Jargon File: //[[http://www.catb.org/jargon/html/M/Murphys-Law.html|Murphy's Law]]//
+  * [[wiki:Accepted]] The principle is widely known and it's validity is assumed. Nevertheless sometimes it is rather used as a kind of joke instead of as design advice. See for example Jargon File: //[[http://www.catb.org/jargon/html/M/Murphys-Law.html|Murphy's Law]]//
 /*  * [[wiki:Questioned]]*/
@@ Line 80: / Line 82: @@
   * [[Easy to Use and Hard to Misuse]] (EUHM): Because of ML an interface should be crafted so it is easy to use and hard to misuse. EUHM is the application of ML to interfaces.
   * [[Uniformity Principle]] (UP): A typical source of mistakes are differences. If similar things work similarly, they are more understandable. But if there are subtle differences in how things work, it is likely that someone will make the mistake to mix this up.
-  * [[Invariant Avoidance Principle]] (IAP): Invariants are statements that have t be true in order to keep a module in a consistent state. ML states that eventually an invariant will be broken resulting in a hard to detect defect. IAP states that invariants should therefore be avoided. So IAP is the application of ML to invariants.
+  * [[Invariant Avoidance Principle]] (IAP): Invariants are statements that have to be true in order to keep a module in a consistent state. ML states that eventually an invariant will be broken resulting in a hard to detect defect. IAP states that invariants should therefore be avoided. So IAP is the application of ML to invariants.
 ==== Contrary Principles ====
@@ Line 161: / Line 163: @@
 <code java>
-Date date1 = new Date(2013, 01, 16);
+Date date1 = new Date(2013, 01, 12);
 Date date2 = date1;
-System.out.println(date1); // Sun Feb 16 00:00:00 CET 3913
+System.out.println(date1); // Sun Feb 12 00:00:00 CET 3913
-System.out.println(date2); // Sun Feb 16 00:00:00 CET 3913
+System.out.println(date2); // Sun Feb 12 00:00:00 CET 3913
 date1.setMonth(2);
-System.out.println(date1); // Sun Mar 16 00:00:00 CET 3913
+System.out.println(date1); // Sun Mar 12 00:00:00 CET 3913
-System.out.println(date2); // Sun Mar 16 00:00:00 CET 3913
+System.out.println(date2); // Sun Mar 12 00:00:00 CET 3913
 </code>
-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 "two-digit", so 1900 is added to it. So there are plenty of possibilities for making mistakes. And sooner or later someone will make them.
 Because of these and several other flaws in the design of the Java date API, most of the methods in ''Date'' are deprecated and also the newer ''Calendar'' API will be replaced by a [[http://openjdk.java.net/jeps/150|new API]] in Java 8.
@@ Line 186: / Line 188: @@
   * [[wiki>MurphysLaw]]
+===== Discussion =====
+Discuss this wiki article and the principle on the corresponding [[talk:principles:Murphy's Law|talk page]].