Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ncar!boulder!sunybcs!bingvaxu!leah!itsgw!imagine!pawl19.pawl.rpi.edu!jefu
From: jefu@pawl19.pawl.rpi.edu (Jeffrey Putnam)
Newsgroups: comp.software-eng
Subject: Re: Style rules for C shops
Message-ID: <797@imagine.PAWL.RPI.EDU>
Date: 27 Apr 88 10:54:38 GMT
References: <12120@santra.UUCP> <3850009@wdl1.UUCP>
Sender: news@imagine.PAWL.RPI.EDU
Reply-To: jefu@pawl19.pawl.rpi.edu (Jeffrey Putnam)
Organization: RPI Public Access Workstation Lab - Troy, NY
Lines: 68

In article <3850009@wdl1.UUCP> rion@wdl1.UUCP (Rion Cassidy) writes:
>news@santra.UUCP (news) writes:
>>In article <528@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:

   (edited in the interests of brevity - i hope that i did not change
    the substance of any of the comments)

>>>      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 have found that it is less important to force everyone into using
a single style than to get them to use their personal style consistently.
The only major exception to this is in naming visible objects (variables,
functions).  The important thing seems to be internal consistency, not
global consistency - but see below.

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

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

Whee!  (again, see below)

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

Sounds fairly flexible.  Good.  

All this seems to me to be ignoring the state of the art in software
and hardware.  It does not seem impossible to construct a program
construction tool that would allow each programmer to build a program
in whatever style seems appropriate to her, (with the possible
exception again of globally visible objects) and would be able to
present the same code (even at the same time) to another user with
another style (an example-based formatting system and a smart
displayer).  Even local variable names could be mapped if desired
(that is, it is easy enough to see how to map "HelloThere" into
"hello_there", or even, given enough power in the tool, into "Hello There!"
(since lexical analysis is only really needed in parsing streams of
raw characters)).  Comments could be put in boxes or different fonts,
the scope of loops could be indicated with vertical bars - or boxes,
rather than using indentation.  Compiler directives could be hidden or
eliminated (Im thinking of some of my C programs that end up with
_lots_ of preprocessor lines, and i would like (optionally) to not
even see them, only the text that is actually generated).  And so
on.

I dont know of anyone who has actually built such a system, but do
not believe it is very far in the future.  Further, though it wont
solve even a major part of software engineering problems, it should
enable us to stop worrying about things like style rules.


jeff putnam  
jefu@pawl.rpi.edu -or- jeff_putnam%rpitsmts@itsgw.rpi.edu
"People would rather believe a simple lie than the complex truth."