How to disable [exported method should have comment or be unexported

[douglarek]

I find lots of codes in golang source are not commented, how can I disable it ?

[dsymonds]

See the README. There are deliberately no ways to selectively enable or disable specific messages. Ignore them if they don't seem relevant.

[douglarek]

@dsymonds OK. i know this issue closed; but btw: any plan for "enable or disable specific messages. " ?

[dsymonds]

No, there are no plans to change that.

[mgood]

Users that want more configurability may want to try gometalinter which wraps golint and a bunch of other tools that do static analysis of Go code. It has a bunch of options to control which tools you want to use, and can filter out warnings you find too noisy. There are also extensions for a bunch of popular editors to integrate with it.

I think it's reasonable for golint to keep things simple and not support lots of configuration options, but gometalinter offers that configurability if you want it.

[mh-cbon]

I can t quiet find the precise option to disable only that warning in gometalinter. All or nothing, for instance the balance is in favor of All, thus keeps being annoyed by undesired messages. Bad experience.

If you know how to disable that specific warning, even better, on portion of code only, drop a message here to explain that.

[mgood]

This option allows you to filter out any messages you want to disable:

-e, --exclude=REGEXP ...  Exclude messages matching these regular expressions.

See gometalinter --help for a list of other options. If you have other questions about using gometalinter please file an issue on that project instead.

[hitxiebing]

how do it?

[tqwewe]

For command line:

gometalinter --exclude="\bexported \w+ (\S*['.]*)([a-zA-Z'.*]*) should have comment or be unexported\b"

For VSCode settings.json:

"go.lintTool": "gometalinter",
"go.lintFlags": [
	"--exclude=\"\bexported \\w+ (\\S*['.]*)([a-zA-Z'.*]*) should have comment or be unexported\b\""
],

[targence]

@acidic9

This is not working for me in VS Code 1.19.1
Instead I use this method:

    "go.lintFlags": [
        "--disable-all",
        "--enable=golint",
        "--config=~/.gometalinter"
    ]

cat ~/.gometalinter

{
  "Exclude": ["exported type (\\w+) should have comment or be unexported"]
}

[mgood]

@targence that's more of a question for the VSCode Go project, or gometalinter, so it would be better to ask on one of those project instead.

[jiverson]

@targence

This worked for me:

"go.lintTool": "gometalinter",
"go.lintFlags": [
	"--config=${workspaceRoot}/.gometalinter"
]

cat .gometalinter

{
  "Exclude": ["exported \\w+ (\\S*['.]*)([a-zA-Z'.*]*) should have comment or be unexported"]
}

[PeterIttner]

gometalinter seems to disable all linting hints by default or has some other startup problems.
What worked for me is to just use golangci-lint in the settings

.vscode/settings.json:

{
    "go.lintTool": "golangci-lint"
}

[chetanyakan]

Depending on your usage, you might as well just use | grep -v "should have comment or be unexported" after golint command.

EDIT: You could have a makefile command.

TMPFILEGOLINT=golint.tmp

.PHONY: golint
golint:
	@echo Running GOLINT
	@cd server
	$(eval PKGS := $(shell go list ./... | grep -v /vendor/))
	@touch $(TMPFILEGOLINT)
	-@for pkg in $(PKGS) ; do \
		echo `golint $$pkg | grep -v "have comment" | grep -v "comment on exported" | grep -v "lint suggestions"` >> $(TMPFILEGOLINT) ; \
	done
	@grep -Ev "^$$" $(TMPFILEGOLINT) || true
	@if [ "$$(grep -Ev "^$$" $(TMPFILEGOLINT) | wc -l)" -gt "0" ]; then \
		rm -f $(TMPFILEGOLINT); echo "golint failure\n"; exit 1; else \
		rm -f $(TMPFILEGOLINT); echo "golint success\n"; \
	fi

[wwjue]

cat ~/.gometalinter.json
{
"Exclude": ["exported \w+ (\S*['.])([a-zA-Z'.]*) should have comment or be unexported"]
}

[larytet]

lint_filters=( "receiver name should be a reflection of its identity" \
	"should have comment or be unexported"  \
	"comment on exported function" \
	"comment on exported method" "should have comment" \
	"rewrite if-else to switch statement" \
	"if block ends with a return statement, so drop this else and outdent its block" \
	"comment on exported type" "struct field \S+ should be" "method \S+ should be \S+"\
	"method parameter \S+ should be \S+" "func parameter \S+ should be \S+" )
	command=""$GOPATH/bin/golint"  ./..."
for filter in "${lint_filters[@]}"
do
	command="$command | grep -v -E \"$filter\"" 
done

eval "$command"  

[sgehrman]

@larytet where do you put this?

[win-t]

Hi, I know this issue is closed.
I think this lint should be disabled on internal packages (https://golang.org/cmd/go/#hdr-Internal_Directories), internal packages are not publicly available, so forcing everyone to document it is a bit cumbersome.

[win-t]

what do you think @dsymonds ?

[dzrw]

// Hello should have a comment.
func Hello() string {
  return "Hello"
}

To disable this rule selectively, this passive aggressive comment works for me while providing some small relief at the constant interruptions caused by this rule. When in the middle of writing a lot of code this rule is awful, and I wish it could be disabled until I'm done getting my thoughts out into the editor without resorting to wrapping it with another linter.

Unfortunately, this lint rule doesn't detect my snarky comments, so eventually the codebase fills up with exports with useless comments.

[RoestVrijStaal]

For all the ones who ended up here via their internet search machine like me:

gometalinter is dead, use revive

[srics]

For the someone trying to whack this annoyance using revive here are the specific steps:

1. Create a custom config.toml with [rule.exported] line commented out,

$ diff -C 1  defaults.toml .golint_revive_config.toml
...
*** 13,15 ****
  [rule.error-naming]
! [rule.exported]
  [rule.if-return]
--- 13,15 ----
  [rule.error-naming]
! # [rule.exported]
  [rule.if-return]

2. VS Code setting as in,

{
    "go.lintTool": "revive",
    "go.lintFlags": ["--config=~/.golint_revive_config.toml"]
}

[meustrus]

I'd like to give a +1 to @PeterIttner's suggestion of using golangci-lint instead. The instructions above are not the recommended way to install it in VS Code however. See golangci-lint: Editor Integration for the supported installation method.

I personally disagree that documentation comments for all exports always improve code - they quickly lose touch with reality due to developers ignoring them and IDEs actively hiding them, so I prefer to write LongMethodNamesThatSuccinctlyDescribeTheFunction and refactor into smaller methods when I get sick of how long the method name has to be to reflect reality. The assertion that documentation comments are good is made in Effective Go, however, which makes me wonder what other assertions I will surely disagree with. But I respect golint's dedication to enforcing Effective Go, so rather than request changes here, the real solution here is to look elsewhere for a linter that I can agree with.

[ncruces]

@win-t I agree that should be the rule.

The lack of support from these tools for internal packages is staggering. godoc.org is another (I don't want dozens of internal packages listed).

Internal packages solve a real problem: avoiding code duplication without adding to the API surface.

Meanwhile I'll do a @dzrw and add a passive-agressive:

// Hello is internal. DO NOT USE.
func Hello() string {
  return "Hello"
}

[hans-fischer]

In Germany we call tools that try to dominate the developer like go-lint: Schmutz
I installed the tool into my VSCode but after some seconds I knew... I made a mistake by installing it. So how can I remove Schmutz from my VSCode?

[RoestVrijStaal]

@hans-fischer
Learn to disguish the tools first.

go-lint is not a part of Visual Studio Code nor an VSCode extension. It is installed by you via a (bash/cmd/PowerShell) terminal embedded within VSCode (or an Visual Studio Code extension).

In contrast with PHP's composer, Node.js' npm and yarn, Ruby's gem and Python's pip, there isn't such a convenient thing like go uninstall or go remove for undoing a go install. Sadly.

You have to remove the go-lint package by hand.

[virgilm]

I find the go community as the most self-righteous one ever. Basic functionality that is simply missing and dismissed as 'not needed', no 'community sanctioned' tools, an so on.

For what it's worth, golint is suggested as a default tool by VSCode and the noise it generates makes a useful tool unusable, and people will just disable it to avoid the noise.

[ianlancetaylor]

@virgilm Please stay polite. Please follow the code of conduct, which can be seen at https://golang.org/conduct. Thanks.

That said, see https://golang.org/issue/38968.

[virgilm]

Good to see that, it took a while. It's good to have a pointer to that issue here, since this is one of the first hits in google.

I did not mean to be rude, but that is exactly the issue: for new go programmers (even experienced programmers in other languages), it is hard to get up to speed fast, and the reason is not the language, but the ecosystem. The issue you pointed out addresses that, glad to see it's been accepted.

[shopee-jin]

golint ./... | grep -v 'should have comment.*be unexported'

[pratikpc]

I have a question

What's the reason for not adding support to disable lint warnings the way ESLint or even Clang-Tidy would provide as a comparison?

Is it very difficult to achieve for technical reasons?

Something like the linter was not designed with support to disable linter warnings in mind, so adding support would be difficult or is it a Won't Fix thing?

[aleferri]

@pratikpc can't say for sure, but this look like a political stance from the go mantainers.

[ianlancetaylor]

See golang/go#38968.

[CodeForcer]

The lack of ability to disable linting messages is a really poor design choice. There is no logical rationale that should lead the maintainers of this package to conclude our lives would be better without basic control over linting rules. You are not the almighty gods of Go, there are various reasons people may wish to respect one linting rule and not others.

This is a default linter in Visual Studio, and most developers like to use the default linters in a new language, without having to peruse from that point into eternity through code with a bunch of distracted yellow warning messages. It makes files of code less readable and makes it harder to find the things we do care about.

[ianlancetaylor]

@CodeForcer See golang/go#38968.

[virgilm]

I'm seeing (and watching) https://golang.org/issue/38968 for 6 months now. Not clear what it means. Go ahead, deprecate it, archive this repo. Propose a replacement linter.