Is it a good idea to eliminate compiler warnings?

Question

In the past I\'ve worked with -Wall and other switches for gcc to eliminate every compiler warning for projects I\'ve been involved in. Similarly, in Perl, I always program wit

Answer 1

I'm going to move against the pack here and say that there may be some compiler warnings that aren't worth fixing. Example follows:

We have a great deal of code that was written prior to Java 1.5 and generics. It still works. Eclipse also generates literally thousands of warnings about unparametrized collections. Practically all of these collections are limited in scope; they're never going to break. But wait, you may ask; what about the few collections which aren't limited in scope? Aren't you risking a collection somewhere containing an instance of something that should never go in there?

The response is: a lot of that code is also unchanged. It's legacy-ish; no new code is modifying those collections, and that code has been used for years without problems. It's still in our code base, and we would have to maintain it if a bug manifested, but in practice, it's done its job. Spending the time necessary to parametrize all of those generic collections would take time out of other needed projects.

Note the caveats here, then:

• The code has been used for a long time with no bugs reported.
• The code is not undergoing any substantial editing.

If either of these stops being true - say, for instance, a bug suddenly does manifest, and we have to go in and edit - the warnings suddenly become more worthwhile to fix. (Incidentally, they're very inexpensive to fix at this point, too; we can fix the relevant blocks along the way as we fix the bug.)