(by Eric S Raymond (Addison-Wesley, 2004, ISBN 0-13-142901-9))
Rule of Modularity: Write simple parts connected by clean interfaces
Rule of Clarity: Clarity is better than cleverness
Rule of Composition: Design programs to be connected with other programs
Rule of Separation: Separate policy from mechanism; separate interfaces from engines
Rule of Simplicity: Design for simplicity; add complexity only where you must
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do
Rule of Transparency: Design for visibility to make inspection and debugging easier
Rule of Robustness: Robustness is the child of transparency and simplicity
Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust
Rule of Least Surprise: In interface design, always do the least surprising thing
Rule of Silence: When a program has nothing surprising to say, it should say nothing
Rule of Repair: Repair what you can--but when you must fail, fail noisily and as soon as possible
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can
Rule of Optimization: Prototype before polishing. Get it working before you optimize it
Rule of Diversity: Distrust all claims for "one true way"
Rule of Extensibility: Design for the future, because it will be here sooner than you think
Last modified 16 December 2024