Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!sgi!wdl1!rion
From: rion@wdl1.UUCP (Rion Cassidy)
Newsgroups: comp.software-eng
Subject: Re: Style rules for C shops
Message-ID: <3850009@wdl1.UUCP>
Date: 25 Apr 88 20:35:00 GMT
References: <12120@santra.UUCP>
Lines: 46

news@santra.UUCP (news) writes:

>In article <528@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
>>      I am interested in knowing how various C shops implement
>>company-wide style guidelines.  It strikes me that it would be
>>madness to allow everybody to have their own style, as they can
>>be *so* different that it would be difficult for others with a
>>radically different style to maintain down the road. 
>>... I already have the style rules, I just don't know how
>>rigorously it should be mandated.
>
>I have had to think about this issue for a company that practices 
>programming-in-the-large (over 2 million lines of hll source code) with
>the software having a long lifetime (>= 10 years). In an environment 
>like this, where the readability (hence maintainability) of programs is
>of paramount importance, I would not hesitate to promote style rules 
>if I was convinced that they improve readability. The question, though, is
>how do you enforce these rules, i.e., make sure that everyone is using
>them.

I can't claim a great deal of experience in this vien, but it seems to
me that if you're producing that much code that has to be maintained
for that long of a period, you should be doing code reviews,
walkthroughs, or inspections as part of the implementation process
simply to assure the correct functionality.  It would be easy to
additionally check for programming style at the same time; make it
clear to the programmers that this will happen and that their
promotions/raises can be effected if they haven't followed the style
'rules', which brings me to a second point.

The suggestion of having some kind of parser or compiler to check for
programmers following style rules would obviously be too confining and
probably counterproductive to an extent.  I would advocate style
'guidelines'; suggestions for programming style indicating suggested
maximum number of lines per file, function, where comments are needed,
length of variable names, etc. This could be checked when doing the
inspections mentioned above.  This introduces a degree of
subjectivity, but I feel it is preferable to the totally objective,
automated approach discussed.

Rion Cassidy							
Ford Aerospace
rion@ford-wdl1.arpa
...{sgi,sun,ucbvax}!wdl1!rion

Disclaimer: My employer forced me to write this at gun-point.
I assume no responsibility whatsoever for what I've said here.