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.