Coding Standards. was: a style question

[Daniel Mocsny]

In article <1990Nov18.005030.28841 at zoo.toronto.edu> henry at zoo.toronto.edu (Henry Spencer) writes:
>In article <6733 at uceng.UC.EDU> dmocsny at minerva.che.uc.edu (Daniel Mocsny) writes:
>>...I can think of no reason to impose any
>>particular indenting style on a programmer, because a quick run through 
>>a standardizing beautifier will repair any idiosyncrasy.
>
>Nonsense.  There are several reasons for not relying on beautifiers,
>summed up well by the words written over a decade ago in the Indian Hill
>style guide (with my footnote):
>----------
>This committee recommends that programmers not rely on automatic
>beautifiers for the following reasons.
>First, the main person who benefits from good program style is the
>programmer himself.

I apologize for being unduly vague with "programmer". I should have said 
"competent programmer". I assumed a programmer who already believes 
(s)he has a "good" programming style, and is able to write code that 
(s)he can read. I didn't mean someone who loses the ball after writing 
50 lines of spaghetti. Such a programmer definitely should not rely on 
a beautifier (if the beautified output is too different from the
original, it won't assist the programmer's thinking). So the "any 
idiosyncrasies" I had in mind would probably be rather slight. 

However, in the rest of this article, I will try to show that if
beautifiers are deficient, then our definition of "good program style"
must be similarly deficient.

>Automatic beautifiers can only be applied to complete, syntactically
>correct programs and hence are not available when the need for
>attention to white space and indentation is greatest.

This was written 10 years ago. That sounds like a long time in the
world of computers. It especially sounds like a long time in the
C language market, which is quite dynamic and competitive now. Has no 
progress transpired in the meantime, or are we talking about an
inherent limitation of beautifiers? (Remember, in my original comment,
I assumed a programmer who does not need help from a beautifier to
read her/his own code, and I was speaking of a beautifier as a
tool to assist programmers in the job of reading other programmer's
code.)

>It is also felt that programmers can do a better job of making clear
>the complete visual layout of a function or file, with the normal
>attention to detail of a careful programmer\*f.

This is the crux of the original notion in this thread. The question 
was whether a standardized coding style was a good idea. I said I 
favored standards over chaos, in general. Saying the programmer
can do a better job at source formatting is equivalent to saying that
we cannot rigorously define a standardized coding style. A rigorously
defined style would be suitable for implementing in a beautifier
and compliance-checking program. If this is not possible, then what
we call "good program style" must necessarily remain somewhat vague.

A vague standard leaves many details to the discretion of the
programmer. While this probably reduces the value of the standard,
insofar as minimizing the barriers to inter-programmer communication,
it also reduces the potential for disagreements on style. 

>In other words, some of the visual layout is dictated by intent
>rather than syntax.

The standard must not interefere, then, with the details of layout
that depend on programmer intent. However, that still leaves some
question about how syntax shall dictate those portions it dictates.
What will happen when two programmers disagree on the best way to
lay out those portions of their code which are amenable to syntax-
dictated layout? 

Since these two programmers disagree about a detail which is easy
to embed in a beautifier program, since it depends only on syntax, 
then a beautifier program should be able to mediate the style 
disagreement, and allow each programmer to view the other's code
consistently with personal preference. I now modify my original 
garbled claim to the previous sentence.

>Beautifiers cannot read minds.

Then this must also be true of the definition of "good program style".
Everything we can unambiguously state about "good program style" must
be able to live in a beautifier. If we can't write good beautifiers,
then we also can't say exactly what we mean by "good program style",
other than we know it when we see it. :-)

>Finally, it is felt that since beautifiers are non-trivial programs
>that must parse the source,
>the burden of maintaining them in the face of the continuing evolution
>of C is not worth the benefits gained by such a program.

This is almost certainly true if the programming team must maintain 
its own tools. However, in 10 years the market for C language tools 
has grown substantially. The market today can provide the economy of
scale needed to turn the "burdens" of 10 years ago into profitable
opportunities.

I suspect that 10 years ago, the burden of maintaining full-screen 
symbolic debuggers was also not worth the benefits gained by such a
program. Today, of course, we regard an environment lacking such to
be rather deficient.


--
Dan Mocsny				Snail:
Internet: dmocsny at minerva.che.uc.edu	Dept. of Chemical Engng. M.L. 171
	  dmocsny at uceng.uc.edu		University of Cincinnati
513/751-6824 (home) 513/556-2007 (lab)	Cincinnati, Ohio 45221-0171