Do you trust your linters?

Do you find yourself routinely, or even rotely, disabling linter rules on a case-by-case basis?

I love linters and other static-analysys tools. They can catch legitimate bugs. They can make code more readable. They can reduce a lot of annoying, opinionated back-and-forth during code reviews. If you aren’t using linters automatically in your project, you almost certainly should be.

But do you trust them? Does your team?

I frequently see developers disabling their linters on a case-by-case basis.

Of course sometimes this is appropriate or even necessary. Depending on the language and static analysis tool, false positives are a virtual certainty at times.

But if you find yourself routinely, or even rotely, disabling your linter, it’s not doing its job. At the very least, you’re spending extra effort and time disabling the linter, and making the code less readable at the same time. And in many cases, you may be doing this at the expense of the valuable insights the linter may be providing to you.

In fact, I’ve frequently seen linter-suppressing comments that are longer and harder to understand than simply complying with the linter’s suggestion would have been.

So every time you disable a linter rule, you should be asking yourself:

  1. What is this linter rule trying to tell me? Should I actually be changing my code to conform to the rule?
  2. If this is a legitimate false positive, is it a frequent one? Is this linter really worth it? If not, disable the linter.
Share this