Collective Wisdom from the Experts 85
the parameters and return value of a method in many cases doesn’t add any
value, so it shouldn’t be a warning if they are missing. Or, upgrading to a new
version of the programming language may make code that was previously OK
now emit warnings. For example, when Java 5 introduced generics, all the old
code that didn’t specify the generic type parameter would give a warning. This
is a sort of warning I don’t want to be nagged about (at least, not yet). Having a
set of warnings that are out of step with reality does not serve anyone.
By making sure that the build is always clean, I will not have to decide that a
warning is irrelevant every time I encounter it. Ignoring things is mental work,
and I need to get rid of all the unnecessary mental work I can. Having a clean
build also makes it easier for someone else to take over my work. If I leave the
warnings, someone else will have to wade through what is relevant and what
is not. Or more likely, that person will just ignore all the warnings, including
the significant ones.
Warnings from your build are useful. You just need to get rid of the noise to
start noticing them. Don’t wait for a big cleanup. When something appears that
you don’t want to see, deal with it right away. You should fix the source of the
warning, suppress the warning, or fix the warning policies of your tool. Keep-
ing the build clean is not just about keeping it free of compilation errors or
test failures: warnings are also an important and critical part of code hygiene.