+1 from me.
---
It might help that when people do remove some of the more tricky
warnings, that they send a short email on how they did it.
I remember having to walk down the hall to see Peter Ahe a few times
when I was trying to get rid of some of the trickier warnings in some
of my java code.
Using the annotation to suppress the warning should be a last resort.
-kto
Jonathan Gibbons wrote:
The point is noted, but it seems to me that it would be better to
work on removing warnings rather than making it even easier
to continue ignoring them :-)
With the possible exception of the obnoxious proprietary API
warnings from javac (which typically do not occur in the build
anyway), all warnings from javac can be eliminated one way or
another, and we should be doing all we can to have developers
eliminate the warnings in the code for which they are responsible.
Even if we can't clean all the warnings from all the files, I think
it is reasonable to remove all the warnings from any file a
developer edits.
-- Jon
Martin Buchholz wrote:
One significant simple annoyance is that compile errors are hard to find
amongst the mass of warnings, because errors are not identified as such.
It would be very nice if errors were prefixed by "error:" the same
way that warnings are prefixed by "warning:",
making them easy to search for.
Martin
