CSC/ECE 517 Fall 2007/wiki2 9 A3: Difference between revisions
Line 1: | Line 1: | ||
==What is 'Principle of Least Astonishment'?== | ==What is 'Principle of Least Astonishment'?== | ||
The Principle of Least Astonishment states that the result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues. This axiom states that you should do your utmost to write stuff that is not going to astonish, dismay, or confuse the next person who has to look at it later. | The Principle of Least Astonishment states that the result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues. This axiom states that you should do your utmost to write stuff that is not going to astonish, dismay, or confuse the next person who has to look at it later. When two elements of an interface conflict or are ambiguous, the behaviour should be that which will least surprise the human user or programmer at the time the conflict arises, because the least surprising behavior will usually be the correct one. | ||
===Example=== | ===Example=== |
Revision as of 00:26, 24 October 2007
What is 'Principle of Least Astonishment'?
The Principle of Least Astonishment states that the result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues. This axiom states that you should do your utmost to write stuff that is not going to astonish, dismay, or confuse the next person who has to look at it later. When two elements of an interface conflict or are ambiguous, the behaviour should be that which will least surprise the human user or programmer at the time the conflict arises, because the least surprising behavior will usually be the correct one.
Example
The name of a function should reflect what it does. Otherwise, a user of the function will be unpleasantly surprised: [2]
Bad design:
int calculate_salary(int days, int perday) { printf("The customer has worked for %d days and his salary per day is %d dollars", a, b); }
Better design:
int calculte_salary(int days, int perday) { return days * perday; }
As can be seen in the example above, in the first example the name of the method and its functionality does not match. Whereas a better way of coding is the second one in which the functionality and the method name are related.
Good examples can be found at the following websites:
- User interface
- API-Design
- Whidbey System.Configuration
- HtmlUnit
- Verification Through the Principle of Least Astonishment
- How to design Good APIs
- Yield
In addition to function naming, the principle applies to user interface design. Menu items and other controls should have an effect that is obvious based upon their text labels and placement relative to other controls.
Principle of Least Astonishment in fields other than programming
Principle of Least Astonishment is a very common principle that is used in every day life.
Riding in Traffic
The principle of least astonishment can be translated as "ride predictably" i.e. riding in such a way that minimizes surprise. A complete article on it can be found at Riding in Traffic
Moon Walker
A very good article can be found at How Neil Armstrong brought the space program down to earth. On page 3, Armstrong mentions about principle of least astonishment.
Steens Mountain
A decade ago, Prévot and Coe (and colleagues) reported in three papers the evidence they had found of extremely rapid changes of the Earth’s magnetic field recorded in lava flows at Steens Mountain in southern Oregon (USA). The complete article can be found at Steens Mountain which describes how geomagnetists applied principle of least astonishment.
See Also
http://doodleplex.com/glassmaze/2004/10/
References
[1] http://www.faqs.org/docs/artu/ch11s01.html
[2] http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment
[3] http://www.cs.arizona.edu/projects/sumatra/hallofshame
[4] http://www.ibm.com/developerworks/library/us-cranky10.html?dwzone=usability