Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!caen!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Re lint
Message-ID: <15638@smoke.brl.mil>
Date: 30 Mar 91 14:30:34 GMT
References: <1991Mar24.155508.28031@dgbt.doc.ca> <1991Mar30.045058.28687@redsox.bsw.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 21

In article <1991Mar30.045058.28687@redsox.bsw.com> campbell@redsox.bsw.com (Larry Campbell) writes:
-	1) lint
-	2) compile on at least two different platforms (say, System V
-	   and VAX/VMS)
-	3) link
-	4) test
-	5) test some more
-	6) lint all the changes you had to make because of (2), (3), and (4)
-	7) compile, link, and test on four more platforms (Wang VS, IBM
-	   AS/400, HP 3000, PC-DOS)
-	8) lint again
-	9) compile, link, and test on all platforms again

That's fairly reasonable.  I would also suggest, right after "lint",
having one or more C portability experts review the source code, looking
for potential protability problems or outright bugs.  This normally is a
rather cost-effective procedure.  It is also hard to convince management
of the utility of code reviews, structured walkthroughs, and other
professional software development methods, unless the management knows
a lot about software engineering (in which case they will probably be
the ones insisting on it).