RaymondsRules

From TheArtOfUnixProgramming. Outlined here : http://www.catb.org/esr/writings/taoup/html/ch01s06.html

• /RuleOfModularity: Write simple parts connected by clean interfaces.

• /RuleOfClarity: Clarity is better than cleverness.

• /RuleOfComposition: Design programs to be connected to other programs.

• /RuleOfSeparation: Separate policy from mechanism; separate interfaces from engines.

• /RuleOfSimplicity: Design for simplicity; add complexity only where you must.

• /RuleOfParsimony: Write a big program only when it is clear by demonstration that nothing else will do.

• /RuleOfTransparency: Design for visibility to make inspection and debugging easier.

• /RuleOfRobustness: Robustness is the child of transparency and simplicity.

• /RuleOfRepresentation: Fold knowledge into data so program logic can be stupid and robust.

• /RuleOfLeastSurprise: In interface design, always do the least surprising thing.

• /RuleOfSilence: When a program has nothing surprising to say, it should say nothing.

• /RuleOfRepair: When you must fail, fail noisily and as soon as possible.

• /RuleOfEconomy: Programmer time is expensive; conserve it in preference to machine time.

• /RuleOfGeneration: Avoid hand-hacking; write programs to write programs when you can.

• /RuleOfOptimization: Prototype before polishing. Get it working before you optimize it.

• /RuleOfDiversity: Distrust all claims for “one true way”.

• /RuleOfExtensibility: Design for the future, because it will be here sooner than you think.