Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!zaphod.mps.ohio-state.edu!think.com!redsox!campbell
From: campbell@redsox.bsw.com (Larry Campbell)
Newsgroups: comp.lang.c
Subject: Re: Re lint
Message-ID: <1991Mar30.045058.28687@redsox.bsw.com>
Date: 30 Mar 91 04:50:58 GMT
References: <1991Mar24.155508.28031@dgbt.doc.ca>
Reply-To: campbell@redsox.bsw.com (Larry Campbell)
Organization: The Boston Software Works, Inc.
Lines: 30

In article <1991Mar24.155508.28031@dgbt.doc.ca> don@dgbt.doc.ca (Donald McLachlan) writes:
-Gee what a novel concept. 1) compile as normal.
-			  2) let the compiler find "normal" bugs.
-			  3) fix them
-			  4) code still does something funny, use lint.
-
-Isn't that what everyone does? ... If not, why not?

You forgot to mention that in step (4), the code often won't do something
"funny" until it's been frozen and shipped and installed at two or three
hundred sites, at which point it's no longer funny, it's too late to fix it,
and you have a lot of pissed off customers.  Around here, the sequence is
more like:

	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

Only then do I start to feel comfortable with the code.
-- 
Larry Campbell             The Boston Software Works, Inc., 120 Fulton Street
campbell@redsox.bsw.com    Boston, Massachusetts 02109 (USA)