add consistent linter

[blizzy78]

This PR adds https://github.com/blizzy78/consistent as a new linter. This linter checks that common Go constructs are used consistently.

This linter is similar to go-consistent, but not quite the same. go-consistent uses auto-detection, while this linter must be configured manually. I also believe that this linter checks things more thoroughly than go-consistent, including an extensive test suite which also tests for false positives.

go-consistent has been requested in #288. This PR adds much of the requested functionality.

[ldez]

In order for a pull request adding a linter to be reviewed, the linter and the PR must follow some requirements.

Pull Request Description

• It must have a link to the linter repository.
• It must provide a short description about the linter.

Linter

• It must not be a duplicate of another linter or a rule of a linter. (the team will help to verify that)
• It must have a valid license and the file must contain the required information by the license, ex: author, year, etc.
• It must use go/analysis.
• It must have a valid tag, ex: v1.0.0, v0.1.0.
• It must not contain init().
• It must not contain panic(), log.fatal(), os.exit(), or similar.
• It must not have false positives/negatives. (the team will help to verify that)
• It must have tests inside golangci-lint.

The Linter Tests Inside Golangci-lint

• They must have at least one std lib import.
• They must work with T=<name of the linter test file>.go make test_linters. (the team will help to verify that)

.golangci.example.yml

• The linter must be added to the list of available linters (alphabetical case-insensitive order).
  • enable and disable options
• If the linter has a configuration, the exhaustive configuration of the linter must be added (alphabetical case-insensitive order)
  • The values must be different from the default ones.
  • The default values must be defined in a comment.
  • The option must have a short description.

Others Requirements

• The files (tests and linter) inside golangci-lint must have the same name as the linter.
• The .golangci.yml of golangci-lint itself must not be edited and the linter must not be added to this file.
• The linters must be sorted in the alphabetical order (case-insensitive) in the Manager.GetAllSupportedLinterConfigs(...) and .golangci.example.yml.
• The load mode (WithLoadMode(...)):
  • if the linter doesn't use types: goanalysis.LoadModeSyntax
  • goanalysis.LoadModeTypesInfo required WithLoadForGoAnalysis() in the Manager.GetAllSupportedLinterConfigs(...)
• The version in WithSince(...) must be the next minor version (v1.X.0) of golangci-lint.

Recommendations

• The linter should not use SSA. (currently, SSA does not support generics)
• The linter repository should have a CI, tests, a readme and linting.
• The linter should be published as a binary. (useful to diagnose bug origins)

---

The golangci-lint team will edit this comment to check the boxes before and during the review.

This checklist does not imply that we will accept the linter.

[blizzy78]

The linter repository should have a CI, tests, a readme and linting.

I have since added GitHub actions for linting, unit testing and checking code coverage to the linter's repository.

[blizzy78]

It must not contain init().

Just to note, the linter does use an init function at one point to construct an internal lookup map. The init function does not have external side effects. In theory it would be possible to initialize the map using a map literal, but that seems harder to read.

As to performance, the init function only does a bit of twiddling with bits and puts 12 entries into the map. I have not measured how long this takes, but I can't imagine it taking longer than a millisecond or two.

Edit: I have changed the linter such that it no longer uses an init function.

[ldez]

I have some remarks on this linter:

• it's more a meta-linter than a linter
• some rules are the opposite of existing linters
• some rules are already handled by existing linters or can be seen as improvements to existing linters
• the term "consistent" was right with go-consistent due to the autodetection, but without autodetection, it's just meta-linter style rules

[nightlyone]

@ldez just to share an outsiders perspective: After reviewing the linter examples, I believe this linter is very useful on its own for enforcing a certain codingstyle.

Many of the configurable settings still vary in the Go community, so you probably want to be stricter in enterprise level projects with stronger uniformity requirements.

[blizzy78]

Is there anything I can do so that this PR can be merged? Please advise.

[ldez]

#2778 (comment)

[blizzy78]

it's more a meta-linter than a linter

I'm not sure what that means. Should I change anything specific?

some rules are the opposite of existing linters
some rules are already handled by existing linters or can be seen as improvements to existing linters

If you could point me to those existing linters you mentioned, that would be very helpful.

the term "consistent" was right with go-consistent due to the autodetection, but without autodetection, it's just meta-linter style rules

Again, I'm not sure what this means. Do I need to convert my linter to a "meta linter"? If so, how would I go about doing that?