Disable/Enable specific Rules

[steelbrain]

Hi everyone 👋

golint is great but sometimes you want all the rules except one and it would be wonderful to specify it somewhere. Other modern linters like ESLint support it, would be good to have it supported in golint as well.

[deitch]

Been looking for exactly that. E.g. I might not have proper docs on an exported function, but for a given project but might not matter.

[dsnet]

Hi, I'm on the fence about whether this should be done. In the mean time, I would like to gather more information about why this should be a feature.

My thoughts are:

• The purpose of lint is to encourage a consistent style of Go across the community. An individual developer may not agree with its style rules (I don't agree with some of them), but there is a strong benefit to consistency in the Go community. The ability to turn on/off specific rules is a very slippery slope where a person can disable a sufficient number of rules such that the tool can't effectively do its job.
• There are certain rules that lead to many false positives (e.g., it flags something as a style violation that most people would agree is okay). These cases can be annoying, but I would vote that we either tighten the rule or delete these rules than a blanket ability to enable/disable rules.
• Why is the min_confidence flag not sufficient for your use case? Are the confidence values badly chosen and don't fit your use-cases?

[Zanndorin]

@dsnet There is the case that I might have some legacy code which I cannot refactor for reasons of time.

But the real reason I'm here is because I wanted to turn off the warning of not commenting public functions in the internal legacy application im coding in.

[gonzaloserrano]

I'm with @Zanndorin here, I want to disable the exported function XXX should have comment or be unexported check since I'm dealing with legacy code.

[StephenWeatherford]

And what if the community has an established code that does not follow some of the rules? I'm working on an open source project which has about 1500 warnings about not using underlines (and underlines are used because it most closely matches their data model - and they have a confidence of 0.9). It's unreasonable to expect all communities to have the exact same set of rules in all situations.

[dominikh]

It's equally unreasonable to expect golint, which was written for a specific style of Go, to accomodate the needs of all communities that feel it necessary to deviate from that style.

You're free to fork golint and maintain a version specific to your community.

[StephenWeatherford]

@dsnet specifically asked why the feature was needed, and why min_confidence isn't sufficient for particular use cases. So I'm answering that question as requested. Having more flexible options would make the tool more useful in general.

[misham]

It's helpful to omit a rule in on a single line while preserving it for other cases in a project. For example, when implementing callback functions for a library I don't need to add documentation to it or I'm dealing with legacy code.

It would be useful to be able to "turn off" a warning for a specific line by adding a comment, similar to how other linters behave. This way, there is a comment in the code that a lint warning is being ignored and why. The development team can agree or disagree with this as part of a code review.

By being able to control linter's checks in this manner, I can wire it up to a Makefile or a CI script and have it run on every commit without worrying about false positives or instances where I just don't care enough to fix it.

[rana]

Linters are suggestions, not rules. I do observe the linters suggestions, but I sometimes disagree, such as using underscores can be helpful in some cases. Rules are enforced by the compiler and gofmt. Everything else is legal and optional; therefore, it would be nice to disabled some lint suggestions. The challenge is that if i don't conform to every golint suggestion the warnings become too numerous, ignored and I abandon the linter.

[gaffo]

Another example I've hit recently is that the linter tells me that fields need to be named in a certain way, like Id should be ID, or no underscores in names.... however I'm working with other systems which have the opposite rules and already specified the protocol and naming so in this case these rules are just generating noise for me. If I was working in an entirely go world then I'd be totally fine with everything following the go rules but I'm working in an existing ecosystem and that's not likely to change. Therefore I have the option of either using the linter and ignoring tons of things with tons of grep -v in my make file and some non-intuitive scripting to see if the linter returned an error that I cared about so I can fail the build... or I can just turn off the linter. I'd rather have a linter that let me use as much as possible of the rules.

[dominikh]

Third option: fork the tool, implement the rules of your organisation.

[gaffo]

How open would you be to changes that make forks a bit easier but don't implement the feature in the core?

[gaffo]

@dominikh ^?

[dominikh]

@gaffo that's really a question for @dsnet, the maintainer of golint. But you'd also have to be more specific than "changes". What specific changes would make forks easier?