The Tao Of Programming

[zak]

{{ A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity. }} - The Tao of Programming, 4.1 - Geoffrey James
http://www.canonical.org/~kragen/tao...ogramming.html

[LanceGary]

{{ A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity. }} - The Tao of Programming, 4.1 - Geoffrey James
http://www.canonical.org/~kragen/tao...ogramming.html

Then again the program should also work (do what it is supposed to do).

Lance

[danbaron]

[font=courier new][size=8pt]I agree, besides having Tao, it would be nice if a program also does what it purports to do. (Let me know when a program's code is displayed in an art museum.)

The article does make a lot of good points. (Probably a lot of managers looking at a page of code, would have difficulty determining which was the top and which was the bottom.)

"A program should follow the `Law of Least Astonishment'."

Yukihoro "Matz" Matsumoto, the creator of Ruby, uses the above quote.
(It seems that every author who writes a book about Ruby, finds it impossible to say enough wonderful things, about, "Matz" - could it be love?)

"A well-written program is its own heaven; a poorly-written program is its own hell."

When I was in school (for engineering, not programming), there were times when my boss tried to force me to fix someone else's program. Before long, usually thoughts of murder entered my mind. And I convinced my boss that it would be better for me to instead start the program over from the beginning.

"When the program is being tested, it is too late to make design changes."

This is a criticism that is made about programs written in Java and C++.
The big scripting languages, Perl, Python, and Ruby, supposedly falsify this assertion.

Dan