| | 1 | Rules that you need to maintain in your mind before to do anything: |
| | 2 | |
| | 3 | 1. Rule of '''Modularity''': Bee simple and do a clean work. When things are plugged between them is a lot easier to maintain a compatibility and good structure of everything, also, a big gain of stability. |
| | 4 | 1. Rule of '''Clarity''': Clarity is better than cleverness. |
| | 5 | 1. Rule of Composition: Design to be connected to other programs. |
| | 6 | 1. Rule of Separation: Separate policy from mechanism; separate interfaces from engines. |
| | 7 | 1. Rule of Simplicity: Design for simplicity; add complexity only where you must. |
| | 8 | 1. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do. |
| | 9 | 1. Rule of Transparency: Design for visibility to make inspection and debugging easier. |
| | 10 | 1. Rule of Robustness: Robustness is the child of transparency and simplicity. |
| | 11 | 1. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust. |
| | 12 | 1. Rule of Least Surprise: In interface design, always do the least surprising thing. |
| | 13 | 1. Rule of Silence: When a program has nothing surprising to say, it should say nothing. |
| | 14 | 1. Rule of Repair: When you must fail, fail noisily and as soon as possible. |
| | 15 | 1. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time. |
| | 16 | 1. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can. |
| | 17 | 1. Rule of Optimization: Prototype before polishing. Get it working before you optimize it. |
| | 18 | 1. Rule of Diversity: Distrust all claims for “one true way”. |
| | 19 | 1. Rule of Extensibility: Design for the future, because it will be here sooner than you think. |
| | 20 | |
| | 21 | These rules are from the ''Art of Unix Programming'' book by Eric S. Raymond, you can read the original and better explained rules [http://www.faqs.org/docs/artu/ch01s06.html here] |
