more programming rules

[Brian Kelsay]

I can't find the thread now, but Gerald Combs and I and a few others were talking about bad 
programming practices and program bloat and themes, etc.
Well I ran across this article, a review of Eric Raymond's, The Art of Unix Programming.
http://rootprompt.org/article.php3?article=5706 

What I was trying to get at, he said it better than I could:

The Unix philosophy in the words of Doug McIlroy :

    "This is the Unix philosophy: Write programs that do one thing and
    do it well. Write programs to work together. Write programs to
    handle text streams, because that is a universal interface."

Eric abstracts the following rules from the Unix is put together and the 
actions of the "Elders" (When I read this I wondered what they thought 
about being called "The Elders"):

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

---------------------------
Somewhere there is a village missing an idiot.