Keep the Build Clean

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Language cleanup)
m (Fixed language and phrasing)
Line 5: Line 5:
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.
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.
+
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. If I leave the warnings, someone else will have to wade through what is relevant and what is not. Or more likely, just ignore all the warnings, including the relevant ones.
-
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.
+
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. Either fix the source of the warning, suppress this warning or fix the warning policies of your tool. Keeping the build clean is not just about keeping it free of compilation errors or test failures, warnings are an important and critical part of code hygiene.
By [[Johannes Brodwall]]
By [[Johannes Brodwall]]

Revision as of 20:49, 31 October 2008

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. If I leave the warnings, someone else will have to wade through what is relevant and what is not. Or more likely, just ignore all the warnings, including the relevant 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. Either fix the source of the warning, suppress this warning or fix the warning policies of your tool. Keeping the build clean is not just about keeping it free of compilation errors or test failures, warnings are an important and critical part of code hygiene.

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