Re: Code Formatters

[Mike Stark <michael.e.stark@gsfc.nasa.gov>]

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:
> 
> In article <dewar.847124036@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 
>    Mike Stark says
> 
>    "I completely disagree -- we shouldn't be paying software developers to
>    worry about whether the indentation is two or three spaces, or whether
>    the "record" keyword should be on the same line or the next line as the
>    "type" keyword.  We're paying people to think, not to format."
> 
>    This is like saying that we shouldn't be paying novelists to write correct
>    grammar or elegant style, they should just be thinking aout plots, and
>    copy editors will fix things up.

No, Robert, what I am really saying is that a novelist shouldn't have to
worry about
page layout and fonts.  I think by disagreeing "completely" I obscured
the distinction
(and there is one, in my IMHO) between "formatting" and "programming
style".  The
former is an area that is properly left to tools (if you can find one
that will
do what you want -- at NASA we use acronyms heavily, so we like variable
names
such as "IRU_Measurement_Partials" instead of 
"Inertial_Reference_Unit_Partial_Derivatives").  Programming style of
course, should be as Robert says -- correct and elegant.

> 
> Yes, I agree, but only to a certain extent. When you write a report,
> do you use hours fiddling with fonts, margins, etc. on a wysiwyg
> editor, or do you describe the structure of the document and let
> something like Tex/Latex take care of the details? Certainly, those
> tasks which can be done more efficiently by the computer should be
> done that way.
> 
>    In fact the only kind of software engineers that I would be willing to pay
>    are those who DO worry about the style of their code, and take some pride
>    in laying it out and documenting it in an elegant manner.

I agree in the case of programming style.  The problem on formatting is
that there
is more than one elegant manner, and projects want code to read
consistently.  This
to me is where tools come in -- to give the delivered code a
*consistent* style as
well as an *elegant* one.
> 
> Your idea of elegant code may not coincide with mine. As a project
> leader, I want *standardized* layout. Having a standard layout
> which is conformant to the output to some prettyprinter is in my
> opinion a good idea, because it means that those who do not want to be
> burdened with the detailed layout can avoid it. This does not stop
> anyone from documenting the program in an elegant manner, assuming
> that you can stop the prettyprinter from mangling your comments. In my
> experience, this is not much of a problem, unless you insist on very
> arcane commenting styles.
> 
>    Thinking that automatic formatting programs can convert junk code to
>    elegant code, particularly with respect to laying out comments nicely,
>    is like those who in the 60's thought that they could replace docuemtnation
>    by automatic flow chart generators.

This is not at all what I was thinking.  I don't really want to go
beyond maintaining
that we don't pay software developers to worry about whether standard
indentation is
two, three, or four characters.
> 
> We are not talking about converting junk code, but about avoiding
> unnecessary work which could be done by a program.

Mike