Keep the Build Clean - Revision history

Jhannes at 12:39, 7 July 2009

2009-07-07T12:39:48Z

←Older revision		Revision as of 12:39, 7 July 2009
Line 5:		Line 5:
	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 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.		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 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 in many cases doesn't add any value, so it shouldn't be a warning if they are missing. Or, upgrading to a new version of the programming language may make previously okay code now emit warnings. For example, when Java 1.5 introduced generics, all the old code that didn't specify the generic type parameter would give a warning. This is a sort of warning I don't want to be nagged about (at least, not yet). Having a set of warnings that are out of step with reality does not serve anyone.	+	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 in many cases doesn't add any value, so it shouldn't be a warning if they are missing. Or, upgrading to a new version of the programming language may make previously okay code now emit warnings. For example, when Java 5 introduced generics, all the old code that didn't specify the generic type parameter would give a warning. This is a sort of warning I don't want to be nagged about (at least, not yet). Having a set of warnings that are out of step with reality does not serve anyone.

	By making sure that the build is always clean, I will not 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 unnecessary 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 significant ones.		By making sure that the build is always clean, I will not 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 unnecessary 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 significant ones.

Kevlin at 18:29, 6 July 2009

2009-07-06T18:29:47Z

←Older revision		Revision as of 18:29, 6 July 2009
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: "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 just appeared in a compilation and just fixed it?		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 just 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 code base grows, if I don't pay attention, the clutter, cruft, warnings, and problems can 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.	+	When I start a new project from scratch, there are no warnings, no clutter, no problems. But as the code base 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 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. 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.	+	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 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 in many cases doesn't add any value, so it shouldn't be a warning if they are missing. Or, upgrading to a new version of the programming language may make previously okay code now emit warnings. For example, when Java 1.5 introduced generics, all the old code that didn't specify the generic type parameter would give a warning. This is a sort of warning I don't want to be nagged about (at least, not yet). Having a set of warnings that are out of step with reality does not serve anyone.		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 in many cases doesn't add any value, so it shouldn't be a warning if they are missing. Or, upgrading to a new version of the programming language may make previously okay code now emit warnings. For example, when Java 1.5 introduced generics, all the old code that didn't specify the generic type parameter would give a warning. This is a sort of warning I don't want to be nagged about (at least, not yet). Having a set of warnings that are out of step with reality does not serve anyone.

Kevlin: Keep the build clean moved to Keep the Build Clean

2009-07-06T18:22:42Z

Keep the build clean moved to Keep the Build Clean

←Older revision

Revision as of 18:22, 6 July 2009

Kevlin at 09:36, 22 November 2008

2008-11-22T09:36:52Z

←Older revision		Revision as of 09:36, 22 November 2008
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 just now?" On the other hand, have you ever looked at a lone warning that just appeared in a compilation and just fixed it?	+	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 just appeared in a compilation 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, cruft, warnings, and problems can 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.	+	When I start a new project from scratch, there are no warnings, no clutter, no problems. But, as the code base grows, if I don't pay attention, the clutter, cruft, warnings, and problems can 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. 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, I ask the team to change our warning policy. For example, I find that documenting the parameters and return value of a method in many cases doesn't add any value, so it shouldn't be a warning if they are missing. Or, upgrading to a new version of the programming language may make previously okay code now emit warnings. For example, when Java 1.5 introduced generics, all the old code that didn't specify the generic type parameter would give a warning. This is a sort of warning I don't want to be nagged about, at least not yet. 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. 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.

-	By making sure that the build is always clean, I will not 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 significant ones.	+	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 in many cases doesn't add any value, so it shouldn't be a warning if they are missing. Or, upgrading to a new version of the programming language may make previously okay code now emit warnings. For example, when Java 1.5 introduced generics, all the old code that didn't specify the generic type parameter would give a warning. This is a sort of warning I don't want to be nagged about (at least, not yet). Having a set of warnings that are out of step with reality does not serve anyone.
		+
		+	By making sure that the build is always clean, I will not 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 unnecessary 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 significant 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 clean-up. 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.		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 clean-up. 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.

Jhannes: Made examples less Java-specific

2008-11-15T21:13:47Z

Made examples less Java-specific

←Older revision		Revision as of 21:13, 15 November 2008
Line 3:		Line 3:
	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, cruft, warnings, and problems can 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.		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, cruft, warnings, and problems can 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'' <code>@param</code> 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 cause, 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 ''Javadoc''s without~~ the ~~<code>@param</code>, <code>@~~return~~</code>~~, ~~and <code>@throws</code> 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. 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, I ask the team to change our warning policy. For example, I find that documenting the parameters and return value of a method in many cases doesn't add any value, so it shouldn't be a warning if they are missing. Or, upgrading to a new version of the programming language may make previously okay code now emit warnings. For example, when Java 1.5 introduced generics, all the old code that didn't specify the generic type parameter would give a warning. This is a sort of warning I don't want to be nagged about, at least not yet. Having a set of warnings that disagree with reality will not serve anyone.

	By making sure that the build is always clean, I will not 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 significant ones.		By making sure that the build is always clean, I will not 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 significant ones.

Kevlin at 13:34, 1 November 2008

2008-11-01T13:34:22Z

←Older revision		Revision as of 13:34, 1 November 2008
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 just now?" ~~Have~~ you ever looked at ~~the single~~ warning that ~~suddenly popped up~~ in ~~your compiler~~ and just fixed 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?" On the other hand, have you ever looked at a lone warning that just appeared in a compilation 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.	+	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, cruft, warnings, and problems can 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.	+	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'' <code>@param</code> 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 cause, 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 ''Javadoc''s without the <code>@param</code>, <code>@return</code>, and <code>@throws</code> 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.	+	By making sure that the build is always clean, I will not 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 significant 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.	+	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 clean-up. 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]]

Jhannes: Fixed language and phrasing

2008-10-31T20:49:41Z

Fixed language and phrasing

←Older revision		Revision as of 20:49, 31 October 2008
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]]

Jhannes: Language cleanup

2008-10-30T21:20:46Z

Language cleanup

←Older revision		Revision as of 21:20, 30 October 2008
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]]

Jhannes: Added detail about "what to do"

2008-10-30T21:14:54Z

Added detail about "what to do"

←Older revision		Revision as of 21:14, 30 October 2008
Line 3:		Line 3:
	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 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 ~~fix~~ it. ~~Otherwise~~, 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~~.	+	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.

-	~~Warning from your compiler~~ and from your ~~code~~ 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.	+	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.		Warning from your compiler are useful. You just need to get rid of the noise to start noticing them.

Jhannes: Don't invite the devil into your house moved to Keep the build clean

2008-10-30T21:07:29Z

Don't invite the devil into your house moved to Keep the build clean

←Older revision

Revision as of 21:07, 30 October 2008