lint: choose a new default linter setting

[stamblerre]

The proposal to deprecate golint has been accepted: golang/go#38968. We need to pick an alternative default setting. I propose staticcheck.

/cc @hyangah @dominikh

[RoestVrijStaal]

I think revive should be also considered.

Unfortunately I haven't compared the full featureset of both tools. (Some context: revive was the first hit when I sought a linter which obeys me. A linter is meant to be a helpful tool after all).

However, because revive is not sponsored by Google (while staticcheck is), the tool is more independent of the vendor of Golang.

Also I find the documentation of revive more hands-on than the documentation of staticcheck.

Like "Hey nice, here is an enumeration of all the checks which staticcheck supports. But gee, how to turn one on/off? Do I only need to copy S#number? Where is the example file?"

Also "coming soon" (which means "never forever" in practice).

The docs of revive are in one file and a default example config is easy to find.

[dominikh]

@RoestVrijStaal While I'm all for considering all options, I do not feel that your arguments are very fair.

However, because revive is not sponsored by Google (while staticcheck is), the tool is more independent of the vendor of Golang.

I disagree with any notion that Google has influence over Staticcheck, but I also do not see how that is relevant, considering it is the Go project that is going to maintain the vscode-go extension. Google has much more influence on the developers working on the extension (Google employees) than on Staticcheck, a possible default setting in said extension.

Also I find the documentation of revive more hands-on than the documentation of staticcheck.

I may agree with that, in that improving the documentation is an ongoing process of mine and that it could always be better. However:

Like "Hey nice, here is an enumeration of all the checks which staticcheck supports. But gee, how to turn one on/off? Do I only need to copy S#number? Where is the example file?"

This does not seem like a fair complaint whatsoever. Revive's documentation has one section called Available Rules merely listing rules, little different from Staticcheck's list of checks, and several sections concerning configuration (Configuration, Default Configuration, Custom Configuration, ...) – which resemble Staticcheck's section called Configuration, which explains the format of the configuration file, how it is applied, what the default configuration is, and so on.

It would seem to me that both tools require reading two sections of the manual to figure out how to configure the list of checks applied.

Also "coming soon" (which means "never forever" in practice).

Neither tool that currently lacks documentation is Staticcheck. But of course you are right that ideally, these tools should have documentation. And they will soon(tm), likely once they get merged into gopls itself. But, again, these are auxiliary tools, not used by (m)any people.

The docs of revive are in one file and a default example config is easy to find.

Revive's documentation exists in two files, with some information duplicated in both and the file containing the descriptions of rules does not explain how to enable or disable checks, identically to Staticcheck's documentation, which exists in one website with hyperlinks.

I am always happy to improve Staticcheck's documentation and the new user experience, and am working on restructuring parts of it for the next release. The documentation is not set in stone.

I disagree, however, with the idea that Revive is somehow significantly more approachable than Staticcheck. Both tools require reading a manual from top to bottom, and to follow links for extended information.

[hyangah]

When gopls is enabled, maybe we can disable linter by default - hoping that most of the basic checks are done by gopls.

[gopherbot]

Change https://golang.org/cl/279212 mentions this issue: src/goLint: switch the default lint tool to staticcheck