Difference between revisions of "Unix philosophy/Eric S. Raymond"
From Maths
m (They didn't link properly! Fixing links) |
m (Missed one!) |
||
Line 3: | Line 3: | ||
==Rules of the philosophy== | ==Rules of the philosophy== | ||
− | </noinclude># '''[[/Rule of Modularity|Rule of Modularity]]'''{{rTAOUPESR}} - write simple parts connected by clean interfaces | + | </noinclude># '''[[Unix philosophy/Eric S. Raymond/Rule of Modularity|Rule of Modularity]]'''{{rTAOUPESR}} - write simple parts connected by clean interfaces |
# '''[[Unix philosophy/Eric S. Raymond/Rule of Clarity|Rule of Clarity]]'''<ref name="TAOUPESR"/> - Clarity is better than cleverness | # '''[[Unix philosophy/Eric S. Raymond/Rule of Clarity|Rule of Clarity]]'''<ref name="TAOUPESR"/> - Clarity is better than cleverness | ||
# '''[[Unix philosophy/Eric S. Raymond/Rule of Composition|Rule of Composition]]'''<ref name="TAOUPESR"/> - Design programs to be connected to other programs | # '''[[Unix philosophy/Eric S. Raymond/Rule of Composition|Rule of Composition]]'''<ref name="TAOUPESR"/> - Design programs to be connected to other programs |
Latest revision as of 02:12, 20 September 2016
Stub grade: C
This page is a stub
This page is a stub, so it contains little or minimal information and is on a to-do list for being expanded.The message provided is:
I link to this so much it'd actually be good to have my own version. This is taken from the OLD wiki page here which I STILL link to! Eric S. Raymond was/is one of my heroes but I did loose a tiny bit of awe/respect when I saw him trolling on the GCC mailing list once!
Rules of the philosophy
- Rule of Modularity[1] - write simple parts connected by clean interfaces
- Rule of Clarity[1] - Clarity is better than cleverness
- Rule of Composition[1] - Design programs to be connected to other programs
- Rule of Separation[1] - Separate policy from mechanism, separate interface from engines
- Rule of Simplicity[1] - Design for simplicity; add complexity only when you must
- Rule of Parsimony[1] - Write a big program only when it is clear by demonstration that nothing else will do
- Rule of Transparency[1] - Design for visibility to make inspection and debugging easier
- Rule of Robustness[1] - Robustness is the child of transparency and simplicity
- Rule of Representation[1] - Fold knowledge into data so program logic can be stupid and robust
- Rule of Least Surprise[1] - In interface design, always do the least surprising thing
- Rule of Silence[1] - When a program has nothing surprising to say it should say nothing
- Rule of Repair[1] - When you must fail, do so noisily and as soon as possible
- Rule of Economy[1] - Programmer time is expensive, conserve it in preference to machine time
- Rule of Generation[1] - Avoid hand-hacking; write programs to write programs when you can
- Rule of Optimisation[1] - Prototype before polishing. Get it working before you optimise it
- Rule of Diversity[1] - Distrust all claims for "one true way"
- Rule of Extensibility[1] - Design for the future, because it will be here sooner than you think
Notes
References
- ↑ 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