Warning levels

Over my career, I’ve noticed that a significant number of programmers ignore compiler and linter warnings. They either turn the warning levels down or just ignore the output. I’ve worked with teams using SonarQube that would have tens of thousands of warnings that they wouldn’t even look at.

These warnings aren’t put in your tools just to entertain you. They’re there because this is a potential problem and that perhaps you should pay some attention.

If you’re heading out snowshoeing and see the sign “These trails are not for novices!”¹, you might want to think for a moment, about whether you are sufficiently prepared. Likewise, if you’re hiking and see a sign “Active bears in area”, you might want to consider what that means. Neither one means that you are guaranteed to be in trouble. The trails might be fine, and you may never see a bear, but it’s worth thinking for a moment. That one warning you don’t pay attention to, might be the one where actual danger resides.

The same is true for our compiler and linter warnings.

In the case of compiler and linter warnings, when you have thousands of warnings coming up, it’s almost guaranteed that a small handful of those are legitimate places where we have actual bears dangers. Some place where the tools have identified that something you’re doing is incorrect. Except that you’ll never see the real problem when there are thousands of other warnings trying to get your attention.

So what should we do?

My advice is simple: Turn up the warnings to the highest level and then fix every warning.

Yes, this will likely take a long time if your codebase has been around for a while. Yes, it’s absolutely worth doing.

A frequent comment I get at this point is: “But we don’t agree with some of the linter warnings. It requires us to put our braces here and we like braces over there.”

So change the linter rules — don’t assume that the default set of rules are reasonable or correct. Make the linter enforce the rules that you think are correct. You and your team know more about the codebase that you are maintaining than the person who wrote the default linter rules. Make the tool fit what you’re doing, not the other way around.

Turn on all the warnings and fix them. Hidden among all the warnings will be legitimate problems that need to be fixed. Problems that you can’t see right now.