(^84) 97 Things Every Programmer Should Know
Keep the Build
Clean
Johannes Brodwall
HOUAVE Y EVER LOOKED AT a list of compiler warnings the length of an
essay on bad coding and thought to yourself, “You know, I really should do
something about that...but I don’t have time just now”? On the other hand,
have you ever looked at a lone warning that appeared in a compilation and
just fixed it?
When I start a new project from scratch, there are no warnings, no clutter, no
problems. But as the codebase grows, if I don’t pay attention, the clutter, the
cruft, the warnings, and the problems can start piling up. When there’s a lot of
noise, it’s much harder to find the warning that I really want to read among the
hundreds of warnings I don’t care about.
To make warnings useful again, I try to use a zero-tolerance policy for warn-
ings from the build. Even if the warning isn’t important, I deal with it. If it’s
not critical but still relevant, I fix it. If the compiler warns about a potential
null-pointer exception, I fix the cause—even if I “know” the problem will
never show up in production. If the embedded documentation (Javadoc or
similar) refers to parameters that have been removed or renamed, I clean up
the documentation.
If it’s something I really don’t care about and that really doesn’t matter, I ask the
team if we can change our warning policy. For example, I find that documenting