Principles Wiki

User Tools

Site Tools

You are here: Principles Wiki » Principles » Uniformity Principle (UP)
principles:uniformity_principle

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:uniformity_principle [2021-05-19 09:49] – old revision restored (2021-05-11 17:19) 2a04:ac00:4:d29:5054:ff:fe00:d387principles:uniformity_principle [2021-09-02 12:50] – old revision restored (2021-05-19 09:48) 65.21.179.175
Line 6: Line 6:
 ===== Context ===== ===== Context =====
 /* fill in contexts here: */ /* fill in contexts here: */
-  * [[contexts:Object-Oriented Design]] +  * [[contexts:Object-Oriented Design]]  
-  * [[contexts:API Design]] + 
-  * [[contexts:Architecture]] +
-  * [[contexts:User Interface Design]] +
-  * [[contexts:Implementation]] +
-  * [[contexts:Documentation]]+
 ===== Principle Statement ===== ===== Principle Statement =====
  
-Solve similar problems in the same way. +Solve similar problems the same way.
  
 ===== Description ===== ===== Description =====
- 
-Software design comprises many similar tasks. There are plenty of design decisions that are similar to ones taken before. UP tells that a design is good when similar design problems are solved the same way. UP can be applied to a large variety of problems: naming identifiers, ordering parameters, deciding upon framework or library usage, etc.  
- 
-Striving for consistency and always using the same solutions also means that it can be a good idea to apply a "bad" or less-well suited solution for the sake of consistency. If for example a bad naming scheme is used throughout the whole project, it is advisable not to break it as an inconsistency in the naming scheme would be worse than applying the bad naming scheme everywhere. 
  
  
 ===== Rationale ===== ===== Rationale =====
- 
-Following UP reduces the number of different solutions. There are fewer concepts to learn, fewer problems to solve and fewer kinds of defects that can occur. So the developers, whether the original ones or the maintainers, have an easier task in creating, understanding, and maintaining the software. By reducing variety in the design, the software becomes easier (see [[Keep It Simple Stupid|KISS]]). 
  
  
Line 32: Line 22:
  
   * Use the same naming scheme everywhere   * Use the same naming scheme everywhere
-  * Use the same techniques, mechanisms, libraries, and frameworks everywhere+  * Use the same techniques and mechanisms everywhere
   * In similar methods use the same order of parameters   * In similar methods use the same order of parameters
- 
- 
 ===== Caveats ===== ===== Caveats =====
  
-UP demands solving similar problems in the //same way// and not just in a similar way. This is crucial as subtle differences can be dangerous. These small differences are created easily. Sometimes it is impossible to do two things exactly the same way. And also over time two modules may slowly diverge. So it is sometimes better to have two modules work completely differently than to allow for these subtle differences as they easily lead to misconceptions and mistakes (see [[Murphy's Law|ML]]). +See section [[#contrary principles]].
- +
-See also section [[#contrary principles]].+
  
  
 ===== Origin ===== ===== Origin =====
- 
-This principle is newly proposed here. Nevertheless the idea is not new and should be pretty intuitive to every developer. 
  
  
Line 61: Line 45:
 ==== Generalizations ==== ==== Generalizations ====
  
-  * [[Murphy's Law]] (ML): 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.+  * [[Easy to Use and Hard to Misuse]] (EUHM): Uniform interfaces are easier to use than others.
  
 ==== Specializations ==== ==== Specializations ====
Line 69: Line 53:
 Note that UP can be contrary to virtually every other principle as it demands neglecting other principles in favor of uniformity. Note that UP can be contrary to virtually every other principle as it demands neglecting other principles in favor of uniformity.
  
-  * [[Keep It Simple Stupid]] (KISS): Although UP normally reduces complexity, sometimes UP demands more complex solutions because they are already applied elsewhere and for the sake of uniformity shall also be applied in simpler contexts where they would not be necessary.+  * [[Keep It Simple Stupid]] (KISS): Sometimes UP demands more complex solutions because they are already applied elsewhere and for the sake of uniformity shall also be applied in simpler contexts where they would not be necessary.
   * [[Model Principle]] (MP): UP may demand adhering to a certain naming scheme, which may not be best with respect to MP. See [[#example 1: naming schemes]].   * [[Model Principle]] (MP): UP may demand adhering to a certain naming scheme, which may not be best with respect to MP. See [[#example 1: naming schemes]].
  
Line 98: Line 82:
 ===== Description Status ===== ===== Description Status =====
 /* Choose one of the following and comment out the rest: */ /* Choose one of the following and comment out the rest: */
-/*[[wiki:Stub]]*/ +[[wiki:Stub]] 
-[[wiki:Incomplete]]+/*[[wiki:Incomplete]]*/
 /*[[wiki:Complete]]*/ /*[[wiki:Complete]]*/
  
 ===== Further Reading ===== ===== Further Reading =====
  
-===== Discussion ===== 
  
-Discuss this wiki article and the principle on the corresponding [[talk:principles:Uniformity Principle|talk page]]. 
principles/uniformity_principle.txt · Last modified: 2021-10-18 22:00 by christian