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.

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?

@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.

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.

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.

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.

@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.

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.

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.

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.

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

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

@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?

Honestly, I just read this as you asserting your beliefs. This doesn't match anything I've ever heard from talks by core contributors. Go is improved through rigorous debate, and you're arguing against discussion at all. I'd rather hear this from a maintainer.

If you feel things are fine, why even comment on a closed issue? Just unsubscribe if you don't have the power to meaningfully weigh in.

It's not clear to me why you think that I am arguing against discussion. There is plenty of discussion here. I haven't said that it should stop.

A decision was made on this issue back in #263 (comment). More discussion here isn't going to change that decision. But by all means continue to discuss.

I'm commenting here because I see people expressing unhappiness and dissatisfaction with the Go project, and I'm trying to explain why the decision is what it is, and I'm trying to point out the other options that people have to achieve their goals.

The Go project wants to give you the tools to meet those goals. Where we haven't given you those tools, please let us know.

See this thread...

Perhaps we just need to rename this project. Perhaps people see "lint" and think that it is something they should use. For Go, the thing you should use it called "vet". You should only be using this project, "lint", if you think it has good goals. If you don't, you should be using a different project. There are many tools out there for linting and checking Go code. There is nothing special about this one.

Perhaps. I think the problem here is that once a tool is made "by the official team", people tend to latch on to it, and prefer it over other homegrown tools. This is just my perception. Sometimes those "official tools" don't meet the standards and requirements of some, and community built tools do become more popular. Let's look at history to see how that pans out:

1. pkg/errors -> Go Team realized that errors are too simple, and some additional knobs are needed
2. dependency management -> deb, glide, etc are invented -> Go Team realizes that "just use the HEAD of master" is not as practical, and some additional knobs are needed, and we land on go modules.
3. generics -> cheekybits/genny is invented, because requiring every developer to write code generation themselves is actually really burdensome -> hopefully a generics proposal is accepted soon and the compiler can do the code generation.

Please don't misinterpret this as me being against "start simple and iterate". Indeed, I am all for starting simple and iterating.

If I write a tool for my personal use and the community doesn't like it I would respond in the same way the maintainers have responded here.

If I write a tool to support a community and it doesn't fit their reasonable needs, I would alter it.

Is this tool built for the community or for the maintainers?

On the topic of project goals: is one of the goals of this project to support the reasonable needs of the community?

Is this tool built for the community or for the maintainers?

On the topic of project goals: is one of the goals of this project to support the reasonable needs of the community?

I definitely think these are super relevant question here.

Those are good questions.

I have opened a proposal at https://golang.org/issue/38968 to simply remove the lint program. See that issue for my reasoning.

I encourage people to comment on that issue, preferably about the meta-topic of whether the lint program should exist or not rather than details of what the lint program should do.

Thanks for the comments.

I have opened a proposal at golang.org/issue/38968 to simply remove the lint program. See that issue for my reasoning.

Upvoted

Upvoted. Thank you @ianlancetaylor.

Upvoted thanks @ianlancetaylor

It's similar with the dartfmt maintainers another great framework (Flutter) built for the community, by our beloved Google.

A use case is, not-yet-fixed golint issues...

#393