Disable "should have comment or be unexported" check

[abbasnaqdi]

Please delete the message should have comment or be unexported .
This message will hurt my nerve in vscode and I'm not endearing these messages in my code yet.

Whenever necessary, I add to my comment code and do not need to display this message.
What is the reason why you decide for me and make sure you comment on the code?

[andybons]

Thanks for the issue.

Sorry, but this check will remain intact since it's within the scope of the tool. CodeReviewComments states:

All top-level, exported names should have doc comments, as should non-trivial unexported type or function declarations. See https://golang.org/doc/effective_go.html#commentary for more information about commentary conventions.

Also, from the readme:

The suggestions made by golint are exactly that: suggestions. Golint is not perfect, and has both false positives and false negatives. Do not treat its output as a gold standard. We will not be adding pragmas or other knobs to suppress specific warnings, so do not expect or require code to be completely "lint-free". In short, this tool is not, and will never be, trustworthy enough for its suggestions to be enforced automatically, for example as part of a build process.

I'm sorry this is getting on your nerves. You can use gometalinter in place of golint which lets you disable certain checks as I understand it.

[jackson-sandland]

The issue is that most of the time if you are writing small functions, functions names will be trivial. The tool scope says that non-trivial unexported type or function declarations should have doc comments. This should not be default behavior.

[jirfag]

golangci-lint disables this annoying warning by default

One of good software engineering practices is to produce self-documenting code. Which means that the code should be written in such a way, so that documentation becomes unnecessary (in most cases) as it wouldn't add any useful information. This linting rule ruins the practice.

[andriykutsevol]

You are like a child. Have you ever worked on a limited budget and time?
Most people work this way today.
No one is interested in all these lyrics.

[ianlancetaylor]

@andriykutsevol Please stay polite. Please follow the Code of Conduct at https://golang.org/conduct. Thanks.

[sundbergad]

I am new to golang coding but have as my first issue found this to be very disturbing.
In my case even with flaws. This is the mess I got... so what is wrong with my exported function name ```
func SizeOfDatatype(){
... implementation ....
}

----
 comment on exported function SizeOfDatatype should be of the form "SizeOfDatatype ..." 
 --- 

To me this makes no sence and as many of you guys mention, make it ignorable at least ... Please

[szank]

I feel like I need to strongly oppose the flood of negative remarks about golint in this thread.

In my opinion golint, enforced exported method comments and godoc is a boon for the language and for the developers.

Forced documentation means that:

1. You need to think about what to export. If function/type/const need not to be exported, you don't need to write documentation for it. It's a good incentive to export only what's necessary.

2. Ease of adding documentation to the code and the common docs presentation format (godoc) is one of the reasons why I consider go's open source libraries the best documented libraries in any language I have seen.

3. Ease of adding documentation allows people to create PRs to fix just documentation in the open source library they are using. Which is a great thing.

4. In my team the golint have created an environment where we held each other accountable for maintaining proper documentation for our internal code. I guess this would happen anyway, but it's easier to do it when you have external tools enforcing this.

Still, documentation of some go's open source libraries leave me wanting, but in general I am very very grateful for golint and godoc.

It makes my work much, much easier.

[sundbergad]

szank, it may be that you and your team need it, however my team and I don't need it and with the flaws in the warning that I've commented above, we don't see why it isn't an option to enable/disable as a minimum.

As an example I've written like this and get the warning, still
// SHORT the datatype ports int8
type SHORT int8

[andriykutsevol]

If someone so serious about this things let them do it by themselves.

Once the Linus Torvalds said: Computers have to do the only things that they are told, and nothing more.

[ianlancetaylor]

The lint program is intended to encourage people to write code in a specific style, as described at https://golang.org/wiki/CodeReviewComments with reference to https://golang.org/doc/effective_go.html. If you do not want to write code in that style, then do not run the lint program. The lint program is not supposed to be for all people for all uses; that's what the vet program is for.

[andriykutsevol]

Thank you.

So when I want to write some code quickly, without much worrying about the code style, I use the next settings.json (Visual Studio Code):

{
"workbench.colorTheme": "Visual Studio Light",
"go.buildOnSave": "off",
"go.lintOnSave": "off",
"go.vetOnSave": "off",
"go.buildFlags": [],
"go.vetFlags": [],
"go.useCodeSnippetsOnFunctionSuggest": false,
"go.formatTool": "goreturns",
"go.lintTool": "gometalinter",
"go.lintFlags": ["--disable=all"],
"go.formatFlags": [
"--disable=all"
],
"python.jediEnabled": false,
"python.linting.pylintEnabled": false,
"python.autoComplete.extraPaths": [
"/some/path"
]
}

[Hyvi]

golangci-lint disables this annoying warning by default

golangci-lint is a better choice, I start to use golangci-lint in CI within gitlab

[cmitchellangelo]

I just removed the capital letter and it went away :)