User Tools

Site Tools


principles:principle_of_least_surprise

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
principles:principle_of_least_surprise [2021-09-02 10:47] – old revision restored (2021-05-11 22:19) 65.21.179.175principles:principle_of_least_surprise [2021-10-18 22:15] (current) – +++ restored +++ christian
Line 5: Line 5:
   * Principle of Least Astonishment (PLA)   * Principle of Least Astonishment (PLA)
   * May also be referred to as "rule" or "law" instead of "principle"   * May also be referred to as "rule" or "law" instead of "principle"
 +  * Acronyms sometimes include the "o" for "of": PoLA, PoLS
    
  
 ===== Context ===== ===== Context =====
 /* fill in contexts here: */ /* fill in contexts here: */
-  * [[contexts:Object-Oriented Design]]  +  * [[contexts:Object-Oriented Design]] 
 +  * [[contexts:API Design]] 
 +  * [[contexts:User Interface Design]] 
 +  * [[contexts:Implementation]]
  
 ===== Principle Statement ===== ===== Principle Statement =====
  
 > In interface design, always do the least surprising thing.((Eric S. Raymond: //[[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878339|The Art of Unix Programming: Rule of Least Surprise]]//)) > In interface design, always do the least surprising thing.((Eric S. Raymond: //[[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878339|The Art of Unix Programming: Rule of Least Surprise]]//))
 +
  
 ===== Description ===== ===== Description =====
  
 +Never surprise the user. An interface should behave exactly as the user thinks it behaves. What surprises the user depends on the kind of interface (user interface, module interface) and the type of user (end user, fellow programmer, maintainer). The central idea of PLS is to think about how the user would want to use the interface.
  
  
 ===== Rationale ===== ===== Rationale =====
  
 +Surprises are always a potential source for frustration. A user wants to be in control of the system. If the system does not behave as intended, the user gets disappointed and has to determine how to get the system do what it should do. On the other hand a system that behaves according to the users wishes is pleasant to use.
 +
 +Secondly when everything works as expected, the user will make fewer mistakes. In case of a user interface this means that the user is more effective and in case of a module interface the software will have fewer defects.
  
  
 ===== Strategies ===== ===== Strategies =====
 +
 +  * Separate methods that change an object (commands) from methods asking the object a question (queries) (see [[Command-Query Separation|CQS]])
 +    * This especially means that a query method should not alter the observable object state
 +  * Name all modules in a way that clearly communicates what the module is and does
 +    * Names of classes shall be nouns representing a specific (real-world) concept (see [[Model Principle|MP]])
 +    * Names of ''interfaces'' shall be adjectives describing a specific property. This typically results in names ending with -able
 +    * Names of command methods shall be verbs (in imperative form)
 +    * Names of query methods shall start with get- or is-
 +    * Names of mathematical functions or the like shall be named by the respective concept (like ''sqrt'')
 +    * ...
 +  * Avoid "clever" solutions which are hard to grasp in favor of simple, dumb ones (see [[Keep It Simple Stupid|KISS]])
 +    * [[When in doubt, use brute force]]((http://www.catb.org/~esr/writings/taoup/html/ch01s06.html))
 +    * Tend to use the first solution that comes in mind
 +
 +===== Caveats =====
 +
 +See section [[#contrary principles]].
  
  
 ===== Origin ===== ===== Origin =====
 +
 +The precise origin is unknown. Probably it's //[[http://www.canonical.org/~kragen/tao-of-programming.html|The Tao Of Programming]]// by Geoffrey James.
  
  
 ===== Evidence ===== ===== Evidence =====
 /* Comment out what is not applicable and explain the rest: */ /* Comment out what is not applicable and explain the rest: */
-/+ 
-  * [[wiki:Proposed]] +/*[[wiki:Proposed]]*/ 
-  * [[wiki:Examined]] +/*[[wiki:Examined]]*
-  * [[wiki:Accepted]] + 
-  * [[wiki:Questioned]] +[[wiki:Accepted]]: PLA is widely known and also treated in Eric S. Raymond's //The Art of Unix Programming// 
-*/+ 
 +/*[[wiki:Questioned]]*/
  
  
Line 48: Line 76:
 ==== Specializations ==== ==== Specializations ====
  
 +  * [[Command-Query Separation]] (CQS)
 ==== Contrary Principles ==== ==== Contrary Principles ====
  
Line 61: Line 90:
 {{page>collections:Unix Philosophy (Eric S. Raymond)#Box}} {{page>collections:Unix Philosophy (Eric S. Raymond)#Box}}
  
-===== Example =====+===== Examples =====
  
  
 ===== 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]]*/
  
Line 77: Line 106:
   * [[wiki>PrincipleOfLeastAstonishment]]   * [[wiki>PrincipleOfLeastAstonishment]]
   * Joshua Bloch: //[[http://www.infoq.com/presentations/effective-api-design|How to Design a Good API & Why it Matters]]//   * Joshua Bloch: //[[http://www.infoq.com/presentations/effective-api-design|How to Design a Good API & Why it Matters]]//
 +
 +===== Discussion =====
 +
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:Principle Of Least Surprise|talk page]].
  
principles/principle_of_least_surprise.1630572462.txt.gz · Last modified: 2021-09-02 10:47 by 65.21.179.175