Compilers and programming style (was Re: A question of style)

[Andrew P. Mullhaupt]

In article <1989Dec22.100135.2903 at gdt.bath.ac.uk>, exspes at gdr.bath.ac.uk (P E Smee) writes:
> In article <564 at mwtech.UUCP> martin at mwtech.UUCP (Martin Weitzel) writes:
> >
> 
> >There should be other tools than the compiler, to control programming
> >style, from 'intelligent' beautifiers to proprietary style checkers,
> >but *please* leave the compiler to what K&R and ANSI allows.
> 
> Yep.  The compiler should allow anything which is presently legal.  If it
> wants to include 'do you really mean it' heuristics, they should only be
> applied if you ask for them with some special control argument, and the
> default should be not to use them.  (Actually, though, I'd rather see
> them in something like an expanded and improved lint, or a totally new
> 'is-this-sensible' language checker.  How about, maybe, 'cstyle', by
> analogy with 'style'?)
> 
> I do think, though, that a compiler which will accept code written to
I think you've got a tough problem in developing a really useful utility
here. There seem to be several groups of C programmers with somewhat
incompatible ideas of good style. My special interest so far has been 
the structure of control statements, but this is one of the easier
issues. Some of the really hard ones are things like the choice of
factoring functions within and across source files, which depends on
the author's perception of the likelihood  of modifications to or
re-uses of the code as given. I don't think a C style checker can 
correctly arrive at judgements on this 'global' kind of decision by
looking at the source alone. There are other 'global' issues like
naming conventions, whether to use the preprocessor or not, etc.
which will probably be very hard to arbitrate based on the source.
(It would be possibly to include 'pragmas' which could inform the
source style checker, but I can't see much short of this working well.

	Even in the 'peephole' style issues, there will be disagreement
between programmers on what is good style. I often check the style
used in large source projects by grepping the "for" and "while" and
"do" constructs, to examine some of the gross statistics which can
sometimes indicate the programmers' collective styles in the project. 
The ratio of "for" constructs to "while" constructs seems to have
a bimodal distribution with some projects falling in the 50-50 split
(I fall in this camp) and another group where the ratio is much
higher than one (I call this the "while-averse" style). In the while
averse style, you often find "for" constructs with empty clauses,
(unless the controlled statement contains a continue), a "for"
construct with empty first clause is really a "while" construct in
disguise. Even though I prefer one of these styles to the other,
I would expect to catch flak if I built that into a style checker.

	The issue of style in C programming is compounded by the 
wide range of variation in optimizations provided by different
compilers. On the Sun 4, it turns out that 'unrolling' "for"
constructs does not pay off with Sun's 'cc', (not because the
'rolled' code is fast, but because the compiler generates pretty
stupid code for 'unrolled' loops). The gnu compiler gcc generates
much more sensible code (and returns a 10-fold performance gain
in many loops which occur in APL interpreters, which is of deep
concern to us). It seems that the correct style for 'cc' is to
ignore the unrolling possibility (which we have written macros
for) and stick to straightforward C, but for gcc, the speedup is
too much to ignore and the use of the macros, (which expand to
'non-readable' code) is justified. It seems that to correctly 
judge code, the style checker needs to see both if the macros
(and other preprocessor inputs) are good, and it also needs to
see inside the expansion (preprocessor outputs), and differentiate
on the basis of the nature of optimizations available.

Later,
Andrew Mullhaupt