worley@compass.com (Dale Worley) (08/29/90)
From: bart@videovax.tv.tek.com (Bart Massey)
Thus, I tend to use these things the way I use lint, which is to turn them
on only when I really can't understand why some code is broken, and have
been staring at it for hours. Often, GCC or lint will point out a legal but
questionable line of code which will suddenly make the whole problem clear
to me -- especially if I was trying to read someone else's code :-)...
Thus, you've wasted hours of your time when you could have just run
the compiler with warnings enabled *first*.
I prefer the system that PC Lint (a/k/a Generic Lint a/k/a Gimpel
Lint) has -- you can disable any given warning on a line-by-line
basis. Once you get your code cleaned up, you can run Lint with all
warnings enabled *before* you test-run the code. This gets bugs out
at a much smaller cost than test-running. And for those times when
you really need to do something that Lint complains about, you just
tell it to ignore that particular instance. Thus, you never get
warnings that you routinely ignore.
Dale Worley Compass, Inc. worley@compass.com
[When I used Wizard C, before it turned into Turbo C, one of the nicest
things about it was that the first pass of lint was built into the compiler,
so you automatically got lint warnings whenever you compiled anything. You
could turn off the warnings, either by category via command line switches or
in the source code via /*NOTREACHED*/ and the like, but in most cases fixing
the code to satisfy lint either fixed a bug or improved bad style. -John]
--
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.