Well, as I sit here and churn through some legacy code that was placed in my lap - I mutter this mantra over and over:

"Show me your flowcharts and conceal your tables and I will remain mystified; show me your tables, and I won't need your flowcharts, because they will be obvious."
St. Brooks

I think this has a lot to say about maintainability, and what is most important about documentation. Why? Because an understanding of WHAT the program is doing is so much more important in the first stages of handing a program to somebody. After that comes the details - and they should be fairly clear with a complete understanding of what the program is specified to do (barring creature feep).

Most of my comments are based on this - I strive to make my code understandable, but only after I am sure that it is correct and efficient.

"You can do this in fewer lines . . ."
Well, sure - but does it improve the program? Is it faster? Does it use less resources? Is it more modular? Is it more cohesive? Is it loosely coupled enough?

And the number one question: who is going to have to take care of this when you are done with it?

Jeff

R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
L-L--L-L--L-L--L-L--L-L--L-L--L-L--