kyleb@tekfdi.FDI.TEK.COM (Kyle Bernard) (11/15/90)
I've recently read over the C style guidelines from giza.cis.ohio-state.edu (128.146.8.61) and it seems their usefulness is very limited due to the lack of automated compliance verficiation tools. It's fine to adopt a coding standard (that's exactly what we're looking into) but without automated tools for verifying compliance it becomes unreasonable to enforce the standard. While I agree that code reading has numerous benefits and should be used extensively, I don't think that reading for style compliance is very profitable. Are there any such tools available publically? We have one tool in-house but it is outdated and inflexible. What tools are people using to verify compliance? Kyle. -- uucp: tektronix!tekfdi!honda!kyleb US Mail: Kyle Bernard, Microwave and RF Instruments, Tektronix, Inc. Box 500 MS 58-072, Beaverton OR 97077 Phone: 503-627-3522
cox@stpstn.UUCP (Brad Cox) (11/18/90)
In article <4990@tekfdi.FDI.TEK.COM> kyleb@tekfdi.FDI.TEK.COM (Kyle Bernard) writes: >I've recently read over the C style guidelines from giza.cis.ohio-state.edu >(128.146.8.61) and it seems their usefulness is very limited due to the lack >of automated compliance verficiation tools. Why bother with compliance checking tools. Wouldn't the same effort be spent more productively on a pretty-printer that reformat source to whatever formatting standard you prefer, and let people write as they wish? <I'm referring only to whitespace placement here, not to substantive issues of variable naming, etc, etc.> -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
stank@anvil.WV.TEK.COM (Stan Kalinowski) (11/18/90)
Doing the programming style checking in code reviews actually works
fairly well. With most people, habit quickly takes over and then the
checking for style can be lessened. It is very important to properly
document the standards and communicate it to the newcomers to the
group.
I have seen groups that tried to inforce style guidelines with tools,
it tends to fail. Usually the reason for the failure is that the
group has not come to a concensus on what the style should be,
communication breaks down, and the majority tries to force the
dissenters into the chosen style through the use of tools that
prohibit exceptions. This is not good for a project. Some sort of
compromise must be reached, it is usually best in these situations to
bring in a disinterested third party to set the standard, whereupon
all parties envolved agree to abide by the result. I have heard
stories of engineers writing tools to translate back and forth between
styles, just so they can code in their own style and still comply with
guidelines set by a project. This strikes me as a ridiculous waste of
time and increases the opportunity to cause bugs. Personally, if I
were to come into a group and I found the engineers quibbling over
style guidelines, I would probably quit. Such quibbling is usually a
sign of deep seated interpersonal problems within the group, or
possibly irrationality on the part of one or more engineers.
One project I worked on actually provided emacs macros that, when used
with electric C mode, actually helped the user comply with the coding
standard. The idea behind this was to make compliance easy and
non-compliance more difficult, but not impossible. Remember, there
are always exceptions to any rule, and people tend to exibit better
judgement than machines. If an inflexible enforcement tool is in
place, it may force engineers into awkward coding just to placate the
tools.
stank
US Mail: Stan Kalinowski, Tektronix, Inc., Network Displays Division
PO Box 1000, MS 60-850, Wilsonville OR 97070 Phone:(503)-685-2458
e-mail: {ucbvax,decvax,allegra,uw-beaver}!tektronix!orca!stank
or stank@orca.WV.TEK.COMcml@tove.cs.umd.edu (Christopher Lott) (11/19/90)
In article <4990@tekfdi.FDI.TEK.COM> kyleb@tekfdi.FDI.TEK.COM (Kyle Bernard) writes: >I've recently read over the C style guidelines from giza.cis.ohio-state.edu >(128.146.8.61) and it seems their usefulness is very limited due to the lack >of automated compliance verficiation tools. Gosh, a tool for verifying compliance to a style guide? I think a code review may be the "tool" (certainly the technology) that will accomplish this best. I see a style guide as a way for an organization to produce code that is equally legible to all, and will hopefully be more easily maintained within that environment. Hopefully the style will be accepted and used cheerfully by all, so that all will learn both to read AND write code in the chosen style. On the surface, you can consider purely formatting aspects, but at deeper levels (such as, for example, interfaces for all central lib routines) some style guidance may enhance the coherence of a software system - making it look like it was designed and built by a single mind. chris... -- Christopher Lott Dept of Comp Sci, Univ of Maryland, College Park, MD 20742 cml@cs.umd.edu 4122 AV Williams Bldg 301-405-2721 <standard disclaimers>
donm@margot.Eng.Sun.COM (Don Miller) (11/20/90)
The response to the original poster's request for an automated
style compliance verification tool reinforces my belief that this
is another culturally dependent software development technique.
To "enforce" anything but a quantifiable, documented, agreed upon
standard with "permission" to evolve is, in my experience, fruitless.
Even if the above qualifiers apply to an organization's proposed
coding standard, the beneficial impact will, to a great extent,
depend on the cultural receptivity to such a "constraint".
Beyond the theory, I also have a practical contribution to the original
post. If you indeed have a "pretty printer" that can output
code in the desired standard format, you have your automated style
verifier. Just run the code in question through the pretty printer
and compare the resulting code with the original. As long as the
"pretty printer" isn't doing other non-standard related modifications,
the deviation from the standard will be the result.
In UNIX land (SunOS of course :-):
indent [options] source_file.c ; diff source_file.c source_file.c.BAK ;
{mv source_file.c.BAK source_file.c}
where [options] reflect the standard programming style, to the greatest
extent possible. The mv is necessary since indent replaces the original
source file with the "standardized" equivalent.
Not a perfect solution, but relatively cheap. Previous comments
referencing the questionable value of maintaining tools which must
do parsing independent of the compiler apply.
--
Don Miller | #include <std.disclaimer>
Software Quality Engineering | #define flame_retardent \
Sun Microsystems, Inc. | "I know you are but what am I?"
donm@eng.sun.com | mikec@praxis.co.uk (Michael Chace) (11/21/90)
>>>>> Regarding Re: Automated tools for verifying C style compliance?; cox@stpstn.UUCP (Brad Cox) adds: Brad> In article <4990@tekfdi.FDI.TEK.COM> kyleb@tekfdi.FDI.TEK.COM (Kyle Bernard) writes: >I've recently read over the C style guidelines from giza.cis.ohio-state.edu >(128.146.8.61) and it seems their usefulness is very limited due to the lack >of automated compliance verficiation tools. Brad> Why bother with compliance checking tools. Wouldn't the same effort be Brad> spent more productively on a pretty-printer that reformat source to whatever Brad> formatting standard you prefer, and let people write as they wish? Why not do better from scratch by using a decent editor (ie emacs) that has an adequate mode for editing C source files ? Mike **** ............................................................................. | | Michael Chace | | e-mail : mikec@praxis.co.uk | PraXis Systems | | | Manvers Street | | AMPRNET: g6dhu@g6dhu.ampr.org [44.131.20.3] | Bath, Avon | | AX.25 : G6DHU @ G6DHU-2 or G6DHU @ GB7SDN | BA1 1PX UK | | Phone : (44) [0]225 444700 | | .............................................................................
zvr@ntua.gr (Alexios Zavras) (11/22/90)
In article <3086@exodus.Eng.Sun.COM>, donm@margot.Eng.Sun.COM (Don Miller) writes: > In UNIX land (SunOS of course :-): > indent [options] source_file.c ; diff source_file.c source_file.c.BAK ; > {mv source_file.c.BAK source_file.c} Assuming that indent(1) works, of course. It didn't treat files with lots of #ifdef's very nively, last time I checked... (Of course, really portable programs don't use #ifdef's anyway :-) Anybody ready for starting a "my indent options are better than yours" argument ? -- zvr -- +---------------------------+ Alexios Zavras (-zvr-) | H eytyxia den exei enoxes | zvr@ntua.gr +-----------------------zvr-+ zvr%theseas.ntua.gr@ariadne.csi.forth.gr "Il faut vivre comme on pense, sinon tot ou tard, on finit par penser comme on a vecu"