97 Things Every Programmer Should Know

Chapter 42. Keep the Build Clean

Johannes Brodwall

HAVE YOU 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 warnings 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 the parameters and return value of a method ...