The weekly edition of Programmer Weekly duly arrived in my email inbox last night. This edition contained a blog article arguing that linter comments that disable linting for parts of a given codebase should be banished.

I strongly suggest you read the blog article first, because I am going to strongly argue that it’s wrong. :)

The dispute is whether or not code should be decorated with comments that tell (given) linters to ignore some part of the code, and example from a Go code base might be

// nolint: revive
const INTEGER_OBJ = "INTEGER"

The intent being that the revive linter does not emit any warnings or issues about the use of ALL CAPS and underscores in the constants name.

Now, should this happen, or not. Jeroen Engels argues in his article that, if you wish to ignore warnings like this one from the revive linter about the ALL CAPS, then you should configure your linters to ignore that issue.

The problem is, in my opinion, that configuring a linter (or metalinters) away from the default setting means that that change needs to be synchronised with other members of your team, and communicated to new members.

Worse, if the code is public (eg. FOSS), your project needs to explicitly inform potential contributors about this move away from the default setting.

This might be possible, but a further still exists. Why. Why was the linter configured to ignore that issue.

That needs to be communicated too. Otherwise someone might see the ALL CAPS variable name, think to themselves that it goes against known style guides, and change it anyway.

It’s my opinion that this is why comments exist to tell linters to ignore some code, they also tell developers that the ignore is deliberate. Although, I do feel that just the terse ignore that I presented in the example should be accompanied with a comment for humans, eg. Allow ALL CAPS because reasons.

Having the comment now means that new developers that weren’t around to hear the discussion on why a style choice was made are informed, and can keep the code base consistent (or re-litigate the style choices :-)