principles:principle_of_least_surprise
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
principles:principle_of_least_surprise [2020-10-12 16:31] – old revision restored (2013-02-25 15:23) 159.69.186.191 | principles:principle_of_least_surprise [2021-09-02 10:48] – old revision restored (2021-05-11 22:18) 65.21.179.175 | ||
---|---|---|---|
Line 4: | Line 4: | ||
* Principle of Least Astonishment (PLA) | * Principle of Least Astonishment (PLA) | ||
- | * May also be referred to as "rule" or "law" instead of " | + | * May also be referred to as "Rule" or "Law" instead of " |
Line 12: | Line 12: | ||
- | ===== Principle Statement | + | ===== Definition |
> In interface design, always do the least surprising thing.((Eric S. Raymond: // | > In interface design, always do the least surprising thing.((Eric S. Raymond: // | ||
Line 22: | Line 22: | ||
===== Rationale ===== | ===== Rationale ===== | ||
- | |||
- | |||
- | ===== 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 '' | ||
- | * 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 '' | ||
- | * ... | ||
- | * Avoid " | ||
- | * [[When in doubt, use brute force]]((http:// | ||
- | * Tend to use the first solution that comes in mind | ||
- | |||
- | ===== Caveats ===== | ||
- | |||
- | See section [[#contrary principles]]. | ||
Line 49: | Line 29: | ||
===== Evidence ===== | ===== Evidence ===== | ||
/* Comment out what is not applicable and explain the rest: */ | /* Comment out what is not applicable and explain the rest: */ | ||
- | /* | + | / |
- | | + | [[wiki: |
- | | + | [[wiki: |
- | | + | [[wiki: |
- | | + | |
- | */ | + | |
Line 60: | Line 38: | ||
==== Generalizations ==== | ==== 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 ==== | ==== Specializations ==== | ||
Line 69: | Line 45: | ||
==== Complementary 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' | + | * [[principles:Rule of Repair]] |
- | * [[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. | + | * [[principles: |
- | * [[Uniformity Principle]] (UP): When applying PLS, UP should also be considered for naming modules. | + | * [[principles: |
==== Principle Collections ==== | ==== Principle Collections ==== | ||
- | {{page> | ||
{{page> | {{page> | ||
Line 94: | Line 69: | ||
* [[wiki> | * [[wiki> | ||
* Joshua Bloch: // | * Joshua Bloch: // | ||
- |
principles/principle_of_least_surprise.txt · Last modified: 2021-10-18 22:15 by christian