Keep the Build Clean

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Added detail about "what to do")
(Language cleanup)
Line 1: Line 1:
-
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?
+
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 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.
+
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-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.
+
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 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.
+
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 the code. Don't wait for a big cleanup. Fix it right away.
+
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.
-
 
+
-
Warning from your compiler are useful. You just need to get rid of the noise to start noticing them.
+
By [[Johannes Brodwall]]
By [[Johannes Brodwall]]

Revision as of 21:20, 30 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.

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