Differences

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

--- principles:keep_it_simple_stupid [2021-09-02 14:01] – old revision restored (2021-09-02 10:22) 65.21.179.175
+++ principles:keep_it_simple_stupid [2021-10-20 21:09] (current) – +++ restored and merged +++ christian
@@ Line 15: / Line 15: @@
   * [[contexts:User Interface Design]]
   * [[contexts:Implementation]]
-  *
 ===== Principle Statement =====
@@ Line 27: / Line 27: @@
 A solution that follows the KISS principle might look boring or even "stupid" but simple and understandable. The KISS principle states that there is no value in a solution being "clever" but being easily understandable.
-This does not mean that features like inheritance and polymorphism should not be used at all. Rather they should only be used when they are necessary, or there is some substantial advantage
+This does not mean that features like inheritance and polymorphism should not be used at all. Rather they should only be used when they are necessary or there is some substantial advantage.
 ===== Rationale =====
@@ Line 38: / Line 39: @@
 "When you make your code more flexible or sophisticated than it needs to be, you over-engineer it. Some do this because they believe they know their system's future requirements. The reason that it's best to make a design more flexible or sophisticated today is to accommodate the needs of tomorrow. That sounds reasonable, if you happen to be a psychic." - Refactoring To Patterns - Joshua Kerievsky.
-Another reason to create more complex code is to make optimizations. An optimized code is a more complex code. The Pareto principle also applies in code: a program spends most of the time in a small portion of the code, so it will be wise to concentrate the effort to optimize only that part of the code. Another best practice is to follow the
+Another reason to create more complex code is to make optimizations. An optimized code is a more complex code. Pareto principle applies also in code: a program spends most of the time in a small portion of the code, so it will be wise to concentrate the effort to optimize only that part of the code. Another best practice is to follow the
 "Three rules of optimization": (1. Don't, 2. Don't... Yet, 3. Profile before optimizing), which make sense: to optimize only the code with performance problems. (First author: Michael A. Jackson)
@@ Line 64: / Line 65: @@
 The principle was coined by the American engineer Kelly Johnson referring to the requirement that a military aircraft should be repairable with a limited set of tools under combat conditions ((Ben R. Rich: //[[http://www.nap.edu/html/biomems/cjohnson.pdf|Clarence Leonard (Kelly) Johnson 1910—1990: A Biographical Memoir]]//)).
-The principle of striving for simple solutions sometimes is also called "(rule of) simplicity" ((Eric S. Raymond: //[[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2877917|The Art of Unix Programming]]//)) which was also prominently stated by Tony Hoare in his Turing Award lecture: "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." ((Tony Hoare: //[[http://awards.acm.org/images/awards/140/articles/4622167.pdf|The Emperor’s Old Clothes / The 1980 ACM Turing Award Lecture]]//))
+The principle of striving for simple solutions sometimes is also called "(rule of) simplicity"((Eric S. Raymond: //[[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2877917|The Art of Unix Programming]]//)) which was also prominently stated by Tony Hoare in his Turing Award lecture: "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."((Tony Hoare: //[[http://awards.acm.org/images/awards/140/articles/4622167.pdf|The Emperor’s Old Clothes / The 1980 ACM Turing Award Lecture]]//))
@@ Line 155: / Line 156: @@
 </code>
-Both methods do exactly the same thing. They return a string representing the weekday. Just the implementation is different. Both versions may be seen as simpler than the other depending on the view taken. "weekday2" has less statements and less execution branches. Complexity metrics measuring these aspects (e.g. the [[glossary:cyclomatic complexity]]) will therefore prefer ''weekday2''.
+Both methods do exactly the same thing. They return a string representing the weekday. Just the implementation is different. Both versions may be seen as simpler than the other depending on the view taken. ''weekday2'' has less statements and less execution branches. Complexity metrics measuring these aspects (e.g. the [[glossary:cyclomatic complexity]]) will therefore prefer ''weekday2''.
-On the other hand "weekdays1" uses less language features (just switch, return, and exceptions whereas "weekdays2" needs if, arrays, arithmetic, return, and exceptions). Furthermore in "weekdays1" the relation between input and output can be seen directly and it's clear how it works by just seeing the method. But for understanding "weekday2" there are more details to think about. This is especially true for the range check at the beginning and the index computation in the "return" statement. Clearly this is not particularly difficult but these are aspects which are more difficult than in the other version of the method.
+On the other hand ''weekdays1'' uses less language features (just switch, return, and exceptions whereas ''weekdays2'' needs if, arrays, arithmetic, return, and exceptions). Furthermore in ''weekdays1'' the relation between input and output can be seen directly and it's clear how it works by just seeing the method. But for understanding ''weekday2'' there are more details to think about. This is especially true for the range check at the beginning and the index computation in the ''return'' statement. Clearly this is not particularly difficult but these are aspects which are more difficult than in the other version of the method.
 So it's not objectively clear which of the two implementations KISS prefers without saying which complexity metric to apply. But this ambiguity is not a problem since principles are not meant to be unambiguous and objective. Eventually a human developer has to decide which solution to implement and the principles only give guidelines.