Path: utzoo!mnetor!uunet!nbires!ncar!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.software-eng
Subject: Re: Style rules for C shops
Message-ID: <1066@mcgill-vision.UUCP>
Date: 23 Apr 88 04:51:37 GMT
References: <528@vsi.UUCP>
Distribution: comp
Organization: McGill University, Montreal
Lines: 36

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.  On the other hand, it seems like a
> morale-breaker to have absolute strict rules that leave no room for
> personal style.

As someone else said, anything that a program can change should not be
specified.  In effect, each worker should have a "make this conform to
my idea of nice code" program, and anything that's changed by such
programs should not be required of anyone (es.g.: a tab or four spaces
indent per level, spacing around parens in function calls, spacing
around operators in expressions...).  Then require good documentation
of each module's interface: input arguments and where they're found,
output arguments and where they're found, what happens when the
arguments overlap (:-), what errors can occur and how they're handed
back to the caller, etc....

But also, these personalized pretty-printers shouldn't get much use,
because the only case where one person should work on another person's
code is when the responsibility for that piece of code changes hands as
well.  (The "too many cooks" argument - with software, as with *most*
other things, I believe that "too many" means "more than one".)  The
project should be split up sufficiently that any given routine is the
province of exactly one programmer.  If you have two or more people
working on some piece of code, it's time to subdivide it and parcel the
pieces out.

Of course, that's just my opinion.

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu