don@dgbt.doc.ca (Donald McLachlan) (03/24/91)
> > Well maybe, I have diferent progrraming habits too, but whenever > I run into a bug thats not imediatly obvious, the firts thing > I do is run lint. You will be *amazed* how quickly that will point > you to the problem. > > >-- >Stan Brown P. c. Design 404-363-2303 Ataant Ga. >(emory|gatech|uunet) rsiatl!sdba!stan "vi forever" > > 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?
campbell@redsox.bsw.com (Larry Campbell) (03/30/91)
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)gwyn@smoke.brl.mil (Doug Gwyn) (03/30/91)
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).henry@zoo.toronto.edu (Henry Spencer) (03/31/91)
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