Open andrerfcsantos opened 3 years ago
(cc @bitfield and @tehsphinx)
According to golangci-lint
, the drop in replacement is called revive:
I'd argue however, that students are best served installing and running golangci-lint with the default settings. As that is highly configurable, they can later adjust that to their needs.
staticcheck
is the default linter for VS Code now, and it's probably the most widely useful if we're to recommend a linter.
However, one critical thing golint
does that staticcheck
doesn't is to warn about missing documentation comments for functions, variables, and other public identifiers. We could presumably do this with the auto analyzer, couldn't we?
I am unsure what the best way forward is regarding the linter we use in the analyzer.
Summarizing the options mentioned above:
golanglint-ci run -E revive ...
) or a .golangci.yml
file in each exercise folder. Also I think this linter is a bit harder to understand than the others conceptually since it is a metalinter that combines others.I will ask for input from other maintainers / Go people on Slack.
staticcheck is supposed to include most of the golint checks (see https://github.com/dominikh/go-tools/issues/542), plus many more, so not many reasons to use revive. golangci-lint, being a metalinter bundling many tools, has frequent upgrade issues. For example even now, it cannot run several of its linters on 1.18, and has some peculiar failure modes needing cache cleanup. In most cases, I prefer the combination of goimports + staticcheck. The extra checks in golangci-lint add little value IMHO.
Been thinking a bit more about this and I'm also in favor of using staticcheck
as our standard linter.
golangci-lint
provides. I think staticcheck
provides a reasonable set of checks that should be all we need. I can leave without the comment check. For the exercise we teach comments, the tests themselves are checking if the comments are correct. Not sure we care about these comments in the other exercises.golangci-lint
often has upgrade issuesgolangci-lint
apparently can break checks of the underlying tools making staticcheck's author recommend to use linters directly instead of via golangci-lint.Agreed. I also thought about this more and I have the same feelings about this as @fgm voiced above.
Nevertheless, I think an additional analyzer check for missing comments on exported functions would be good as those (in the correct format) are very idiomatic for Go. This was suggested above by bitfield.
Since golint is unmaintained, deprecated and frozen, maybe we should stop suggesting it and start suggesting alternatives like staticcheck and
go vet
.Or maybe refer to IDE integrations, like we do with
gofmt
.Relevant issue: https://github.com/golang/go/issues/38968