Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Re lint
Message-ID: <1991Mar31.045711.29403@zoo.toronto.edu>
Date: Sun, 31 Mar 1991 04:57:11 GMT
References: <1991Mar24.155508.28031@dgbt.doc.ca> <1991Mar30.045058.28687@redsox.bsw.com> <15638@smoke.brl.mil>
Organization: U of Toronto Zoology

In article <15638@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>-	1) lint
>-	2) compile on at least two different platforms ...
>-	3) link
>-	4) test
>-	...
>That's fairly reasonable.  I would also suggest, right after "lint",
>having one or more C portability experts review the source code...

Also, around the same time, have the author prepare a regression test,
and have that included in the review.  Every minute I've ever spent
writing regression tests has been richly repaid in bugs found and in
assurance that later changes have not introduced obvious bugs.

For those who don't know what a regression test is, it's a set of test
procedures and data that try to exercise the program fairly thoroughly,
plus a comparison procedure that checks the results against expected
results.  (It is important that the checking be automatic or nearly so.)
The initial regression test mostly tries to check out main cases and
boundary conditions; checking of error conditions is also good but can
be much harder to arrange.  Every time a bug is found in testing, data
that demonstrates it gets added to the regression test, so you can be
sure it hasn't come back.

And for extra credit, try convincing the suppliers of your compiler and
operating system to do the same.  God knows, few enough of them do it,
to judge by all the stupid bugs and reappearing bugs...
-- 
"The stories one hears about putting up | Henry Spencer @ U of Toronto Zoology
SunOS 4.1.1 are all true."  -D. Harrison|  henry@zoo.toronto.edu  utzoo!henry