David Mathog wrote On 10/10/07 12:12,:
santosh wrote:
>>David Mathog wrote:
>> Sometimes it would be better if the compilers warned the
programmer s to put in a few more spaces or parentheses so that the
meaning of the code would be unambiguous. That is unambiguous without
having to know arcane details about the how the compiler's parser
functioned .
It's not the compiler's job to teach the programming best coding
practices. No one prevents someone from writing clear, well formatted
source. Unfortunately too many C programmers have IOCCC ambitions.
Witness the recent thread started by Antoninus Twink complaining about
a piece of clear C code.
Teach no, help with, yes. For the sake of argument, imagine that a
compiler had options like:
-Wfor_humans warn on difficult to read code
-Wstyle_fmt1 warn on source code not in specified style
Where the first would catch the "x+++y", and the second would pick up
on deviations from a specified coding style.
The great difficulty is in describing the "style" not
only in precise terms, but in computable terms. As an
exercise, try modifying gcc or another compiler to issue
warnings for departures from
PRE31-C. Never invoke an unsafe macro with
arguments containing assignment, increment,
decrement, or function call
-- CERT C Programming Language Secure Coding Standard
http://www.securecoding.cert.org/
(This rather rough work-in-progress was discussed on c.l.c.
in August of this year.) It's easy enough to get the compiler
to recognize the listed operations, but I think you may have
difficulty teaching it to distinguish "safe" from "unsafe"
macros.
Here is an example of the type of style variant I would love to be able
to flag.
if(some_conditi on)
do_something();
The lack of {} around the conditional code very often leads to errors
during code maintenance, [...]
Aside: This assertion is "very often" made, but is it
backed by measurement? I've been omitting braces from one-
line consequents of `if' and `for' and `while' for more
than three decades, and can't recall coming to grief as a
result.
[...] Also, many projects have coding style standards, but
these are currently impossible to enforce using just the compiler.
[...] The
compiler is clearly a good place to do this since it has to parse the
code thoroughly anyway, and could easily add a few more rules during
that parsing to pick up on things like indent levels, bracket spacing,
and split line if statements.
First observation: It seems to me that the formatting of
the code is among the least important things to worry about.
Badly-formatted code is hard to read, yes, but if it's truly
terrible there's no shortage of code reformatters. If you're
happy with the rearrangements reformatters can make, what's
the point of requiring that they be made by humans instead?
Save human effort for the things machines *aren't* good at.
Second observation: I once shared your view that because
the compiler has to inspect the code anyhow, the compiler is
the logical "pinch point" at which to ensure good practice.
But fifteen or twenty years ago I changed my mind: the job
of the compiler is to translate the source code, not to
enforce some organization's standards. Different standards
apply in different organizations -- even in different projects
within the same organization -- so the compiler's suite of
standards would need to be localizable, which adds to the
complexity of the compiler. It's bad enough dealing with
optimizer bugs; do you also want to handle enforcer bugs?
How much time do you want to spend debugging the scripts
or whatever that describe the local style(s)?
Software engineering is a social activity (yes, even
for the so-called "loners"), and making sure that it is
done well and/or according to standards is a social issue.
Technology influences social issues, but is seldom in and
of itself a cure for social ills.
--
Er*********@sun .com 
