Chapter 42. 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, â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 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 codebase 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 try to use a zero-tolerance policy for warnings from the build. Even if the warning isnât important, I deal with it. If itâs 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 ...
Get 97 Things Every Programmer Should Know now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
