Keep the Build Clean
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 now?" Have you ever looked at the single warning that suddenly popped up in your compiler and just gone about to fix 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 problems, 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-warning tolerance policy. Even if the warning is irrelevant, I deal with it. If it's relevant, but not critical, I still fix it. Javadoc @param tags that refer to deleted or renamed parameters or that don't have a description are cleaned up. If the compiler warns about a potential null-pointer exception, I fix the ambiguity, even if I "know" the problem will never show up. If it's something I really don't care about, I ask the team to change out warning policy. For example, I often prefer writing shorter Javadocs without the @param, @return and @throws tags. For a code base developed with Java 1.4, I don't want warnings about missing generics parameters. 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 it's irrelevant every time I encounter it. If there are warnings I just don't care about, I turn them off in my IDE. Ignoring things is mental work, and I need to get rid of all the mental work I can. This 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 the code. Don't wait for a big cleanup. Fix it right away.
Warning from your compiler are useful. You just need to get rid of the noise to start noticing them.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page