principles:principle_of_least_surprise
This is an old revision of the document!
Table of Contents
Principle Of Least Surprise (PLS)
Variants and Alternative Names
- Principle of Least Astonishment (PLA)
- May also be referred to as “rule” or “law” instead of “principle”
Context
Principle Statement
In interface design, always do the least surprising thing.1)
Description
Rationale
Strategies
Origin
Evidence
Relations to Other Principles
Generalizations
- Easy to Use and Hard to Misuse (EUHM): A module is easy to use if there is no surprise in how it works.
Specializations
Contrary Principles
Complementary Principles
- Fail Fast (FF): FF is about what a module should do in the case of error. PLS on the other hand is about how the module should behave normally. Furthermore it normally is not a surprise that a module fails when there is an error but a module that doesn't fail when it should, behaves strangely.
- Model Principle (MP): PLS is mainly about how module identifier and module behavior relate to each other. MP tells that modules named according to the model are least surprising.
- Uniformity Principle (UP): When applying PLS, UP should also be considered for naming modules.
Principle Collections
Example
Description Status
Further Reading
- Eric S. Raymond: The Art of Unix Programming: Rule of Least Surprise
- Eric S. Raymond: The Art of Unix Programming: Applying The Rule of Least Surprise
- Joshua Bloch: How to Design a Good API & Why it Matters
1)
Eric S. Raymond: The Art of Unix Programming: Rule of Least Surprise
principles/principle_of_least_surprise.1360591389.txt.gz · Last modified: 2013-05-19 22:10 (external edit)