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: <12569@santra.UUCP>
Date: 5 May 88 17:33:31 GMT
References: <12120@santra.UUCP> <3850009@wdl1.UUCP>
Reply-To: nbo@hutcs.UUCP (Nassim Bouteldja)
Organization: Helsinki University of Technology, Finland
Lines: 32

In article <3850009@wdl1.UUCP> rion@wdl1.UUCP (Rion Cassidy) writes:

>>Nassim Bouteldja wrote:
>>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. 

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

We certainly do have code reviews, but we would like to concentrate on
the logical design of the program. It is a bit time-consuming to start
checking on line lengths, procedure lengths, amount of spaces per line,
amount of blank lines, identifier lengths. It can nicely be implemented
as a program that produces metrics on these characteristics. I actually
built such a program and by just glancing at the results of the analysis
I can identify aspects that need closer physical checking. Because 
code reviews are done before system testing, it is inevitable that the
tested and validated programs will differ from the ones submitted at
code review meetings. Therefore, it is worthwhile running the style
metrics before allowing a program to be frozen in the project database.
Furthermore, when a program's life is long, it tends to be modified
along the way either to correct errors or for enhancement purposes. Often,
these kind of activities are not subject to code review checks. So my tool
can be used in those circumstances too, and in general to monitor one
aspect of software quality.