Keep the Build Clean

From WikiContent

Revision as of 21:20, 30 October 2008 by Jhannes (Talk | contribs)
Jump to: navigation, search

Have you ever looked at a list of compiler warnings the length of an essay on bad coding and thought to yourself: "Man, I really should do something about that, but I don't have time just now?" Have you ever looked at the single warning that suddenly popped up in your compiler and just fixed it?

When I start out a project, there are no warnings, no clutter, no problems. But as the code base grows, if I don't pay attention, the clutter, cluft, warnings and problems start piling up. When there's a lot of noise, it's much harder to find the real warning that I really wanted to read among the hundreds of warnings I didn't care about.

To make warnings useful again, I use a zero-tolerance policy about warnings from the build. Even if the warning isn't important, I deal with it. If it's relevant, but not critical, I still fix it. I clean up Javadoc @param tags that refer to deleted or renamed parameters or that don't have a description. If the compiler warns about a potential null-pointer exception, I fix the ambiguity, even if I "know" the problem will never show up in production. If it's something I really don't care about, I ask the team to change our warning policy. For example, I often prefer writing shorter Javadocs without the @param, @return and @throws tags. Or, for a code base developed with Java 1.4, I don't want to deal warnings about missing generics parameters right away. Having a set of warnings that disagree with reality will not serve anyone.

By making sure that the build is always clean, I will 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 mental work I can. Having a clean build also makes it easier for someone else to take over my work.

Warnings from your build are useful. You just need to get rid of the noise to start noticing them. When something appears that you don't want to see, fix it right away. Don't wait for a big cleanup. Don't leave fallen code behind enemy lines.

By Johannes Brodwall

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools