Difference between revisions of "Unix philosophy"

Latest revision as of 02:12, 20 September 2016

Eric S. Raymond

1. Rule of Modularity^[1] - write simple parts connected by clean interfaces
2. Rule of Clarity^[1] - Clarity is better than cleverness
3. Rule of Composition^[1] - Design programs to be connected to other programs
4. Rule of Separation^[1] - Separate policy from mechanism, separate interface from engines
5. Rule of Simplicity^[1] - Design for simplicity; add complexity only when you must
6. Rule of Parsimony^[1] - Write a big program only when it is clear by demonstration that nothing else will do
7. Rule of Transparency^[1] - Design for visibility to make inspection and debugging easier
8. Rule of Robustness^[1] - Robustness is the child of transparency and simplicity
9. Rule of Representation^[1] - Fold knowledge into data so program logic can be stupid and robust
10. Rule of Least Surprise^[1] - In interface design, always do the least surprising thing
11. Rule of Silence^[1] - When a program has nothing surprising to say it should say nothing
12. Rule of Repair^[1] - When you must fail, do so noisily and as soon as possible
13. Rule of Economy^[1] - Programmer time is expensive, conserve it in preference to machine time
14. Rule of Generation^[1] - Avoid hand-hacking; write programs to write programs when you can
15. Rule of Optimisation^[1] - Prototype before polishing. Get it working before you optimise it
16. Rule of Diversity^[1] - Distrust all claims for "one true way"
17. Rule of Extensibility^[1] - Design for the future, because it will be here sooner than you think

Notes

References

1. ↑ ^{1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16} The Art of Unix Programming - Eric S. Raymond