Path: utzoo!mnetor!uunet!mcvax!enea!tut!santra!news
From: news@santra.UUCP (news)
Newsgroups: comp.software-eng
Subject: Re: Style rules for C shops
Message-ID: <12120@santra.UUCP>
Date: 20 Apr 88 13:29:16 GMT
References: <528@vsi.UUCP>
Reply-To: nbo@hutcs.UUCP (Nassim Bouteldja)
Followup-To: comp.lang.misc
Distribution: comp.lang.misc,comp.lang.c
Organization: Helsinki University of Technology, Finland
Lines: 26
Keywords: C style
Summary: How dou you enforce the rules?

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. One solution is to write a program that does style checking according
to your rules and refuses to pass a program to the compiler if the style
used is significantly below the advocated standard. That would, as you
rightly say, penalise individuality and be too demanding on the computer
resources if the checker was run each time a compilation was wanted.
For these reasons, I would rather go for a style analyser that would be 
invoked only once before the software is frozen for release in the
database. Large deviations from the standard would have to report to
management before being allowed to proceed with freezing the software.
This way we can deal with "intelligent" deviations.