Donovan said:
But chasing some error that the compiler warned you about is a potential
timesink, because you turned down warning levels, or because the warnings
were hidden among dozens of lines of noise is an even bigger waste of time.
And chasing some error that the compiler didn't warn you about because
someone added a cast to get rid of the warning is a potential timesink,
Writing a small wrapper around static_cast is a minor inconvenience at worst.\
Any time you're rewriting correct, meaningful code in order to silence a
warning you're wasting time. And, of course, you can't assume that
someone who added a cast had thought about what the code did; they might
have added it just to silence the warning. After all, that's the goal:
your code should compile without warnings. Doesn't matter if it's
correct said:
Of course you understand this -- so how would you go about managing the
problem of noisy warnings ?
Turn 'em off.
Suppose there is a "borderline" warning that is sometimes useful and sometimes
just annoying. (I'd consider this to be such an example) Do you turn warning
levels down, or do you turn them up, but then find some way to supress or
filter the resulting noise ? Or is it your opinion that my premise is just
plain wrong, and there is no such thing as a "borderling" warning ?
Too many programmers today treat the compiler as a surrogate brain, and
rely on warnings to remind them that they haven't thought about the
consequences of what they've done. If you're writing code that converts
a double to an int you'd better know what the limitations on that are,
and you'd better take the time to analyze where the double comes from
and assure yourself that the conversion will do what you need to do.
That's basic software engineering. Warnings don't change that. At best
they become a checklist of places where you haven't finished your work.
There are much more effective ways of doing that, beginning with not
leaving a piece of code until you understand it. That way you don't have
to remember to look at it again later.
Tom DeMarco, in a book called "Controlling Software Projects,"
recommended (perhaps tongue in cheek) that programmers not be allowed to
use compilers; compiling their code would be part of the test phase, not
the development phase.