Path: utzoo!utgpu!watserv1!watmath!att!att!emory!ogicse!zephyr.ens.tek.com!orca.wv.tek.com!anvil!stank
From: stank@anvil.WV.TEK.COM (Stan Kalinowski)
Newsgroups: comp.software-eng
Subject: Re: Automated tools for verifying C style compliance?
Message-ID: <9544@orca.wv.tek.com>
Date: 18 Nov 90 06:58:49 GMT
References: <4990@tekfdi.FDI.TEK.COM>
Sender: news@orca.wv.tek.com
Reply-To: stank@anvil.WV.TEK.COM (Stan Kalinowski)
Organization: Tektronix, Inc., Wilsonville, OR
Lines: 40

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.COM