🚀 go-pugleaf

I disagree with Mr. Paul. The ability to maintain programs after creation 
is indeed vital. The answer does not lie in restricting programmers to 
certain "coding styles". This ensures that programs will never get any
faster, more efficient, or smaller than they currently are. To spend time
optimizing a program, if it deviated from the "coding style", would actually
be a violation of the rules. I have worked on such a project, and I actually
had to fight with managers and QC types to get a technical improvement 
implemented.

Rather than tying the hands of the programmers, the key is to enforce 
DOCMUENTATION of the product. Daily journals, styles of documentation,
reasonable guidelines for comments, and a commitment to maintainable
programs go much farther toward making a project work over time than enforcing
a particuar program style. 

BTW, my project at the time was programming instruments on an automatic test
station. The changes that "violated the style" were necessary because they
turned out to be the only way to get the instrument to work. Management 
actually considered scrapping the instrument rather than change the
"programming style"!

It should also be noted that the work mentioned above was with a previous
employer. My supervision at Boeing has been excellent at letting me solve
programming problems in the way I see fit.


======================================================================
Mark R. Miller                     +    Disclaimer: Opinions expressed  
Boeing Commercial Airplane Co.     +    are mine and mine alone, and    
Seattle, WA                        +    not necessarily those of my     
Internet: miller@b-mrda.boeing.com +    employer.                       
Voicenet: (206) 237-0960           +                                   
                                   +       +++ Phillipians 4:13 +++    
======================================================================