Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!peter
From: peter@athena.mit.edu (Peter J Desnoyers)
Newsgroups: comp.lang.misc
Subject: Re: Style rules for C shops
Summary: automatic conversion loses
Message-ID: <5368@bloom-beacon.MIT.EDU>
Date: 16 May 88 04:09:14 GMT
References: <12120@santra.UUCP> <1962@bgsuvax.UUCP> <12567@santra.UUCP> <4043@killer.UUCP> <12822@santra.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: peter@athena.mit.edu (Peter J Desnoyers)
Distribution: comp.lang.misc,comp.lang.c
Organization: Massachusetts Institute of Technology
Lines: 37

It has been suggested that the way to create uniform coding standards
in a group is to use a beautifier that converts any style of code into
the officially sanctioned style. It has been pointed out that this is
not possible, in the general case, given the current state of the art.

I would suggest that it may not be a good idea, either. One of the
benefits of a reasonable set of code standards is that one person can
pick up another's code and read it or modify it with less effort than
if a multitude of styles are used. (Don't you love modifying code that
is indented differently from the editor defaults you use? I usually
end up reformatting the entire file.) 

Anyway, for some suggestions gleaned from experience with a few groups
that had coding standards -
  Global names - functions and variables - are important. There should
at least be a structure for these names, so that the name identifies
the module. A rule to distinguish function and variable types - e.g.
booleans are named foo_p - might be useful, and might not. You might
want to have all _really_ global names approved by one person.
  File and function headers should be standardized and should contain
enough information. Arguments, description, side effects, and
modification history are good starters. For protocol or compiler
stuff, references (to defining documents) are useful as well. Someone
should create templates for these things, and maybe standard editing
macros like box-region.

These are more management - rather than technical - issues, and should
probably be discussed in the beginning when you set up source code
control and release procedures, and other things like that. I don't
like the idea of checking style by machine - I think it should be
checked by a human during code review. 

Of course, if the program is small - say less than 30 files - you
can probably ignore most of these issues. 

				Peter Desnoyers
				peter@athena.mit.edu