Document expanded list of all linter rules

[sebastien-rosset]

Is your feature request related to a problem? Please describe. It's difficult to sift through the list of rules across all linters.

1. Sometimes a one-liner description at https://golangci-lint.run/usage/linters/ is sufficient because the linter implements a single rule.
2. Some linters implement over 100 rules. For example, govet, gosec, staticcheck and go-critic have many rules.
3. Some linters support extensible rules without recompilation.
4. Some linters seem to be somewhat redundant, maybe because it's difficult to get the complete list of checks.

Describe the solution you'd like Provide a searchable list of all linter rules with categories or tags. Each linter would somehow register all the rules it implements with rule-name, tags, doc.

For example:

Name: G101, Tags: security, Doc: Look for hard coded credentials
Name: G102, Tags: security, Doc: Bind to all interfaces

Name: ST1008, Tags: Stylistic issues, Doc: A function's error value should be its last return value
Name: ST1011, Tags: Stylistic issues, Doc: Poorly chosen name for variable of type time.Duration

A starting point for the list of tags is to use staticcheck and go-critic:

1. Security
2. Code simplifications
3. Misuses of the standard library
4. Concurrency issues
5. Testing issues
6. Code that isn't really doing anything
7. Correctness issues
8. Performance issues
9. Dubious code constructs that have a high probability of being wrong
10. Stylistic issues

Describe alternatives you've considered The list of all supported linters is documented here: https://golangci-lint.run/usage/linters/. Each linter entry in the documentation has a link to the linter github page. So it's possible to manually explore all linter checks, read the documentation of each linter and then decide which linters and which linter checks to use.

[ldez]

Hello,

It is almost impossible to do this or maintain this, due to the number of linters and rules.

related to #1685

[matrixik]

Not sure if this should be posted here or in #1685

Would be great if this also included link back to extended documentation about specific bug. Then IDE could show user clickable link that would open web page with bug.

Shellcheck provide something like that now (go to https://www.shellcheck.net/, click Load random example, after that you will see errors in ShellCheck Output with clickable links to documentation). VS Code show this links when you hover over it and click Quick Fix... (Ctrl+.).

Bandit JSON output example: https://github.com/securego/gosec/issues/127#issuecomment-447820489

[matrixik]

@ldez golangci-lint could provide standardized guidance how linters authors could store all this info so that would be easy for golangci-lint to parse/retrieve and then all of it could be automatic.

[ldez]

golangci-lint is just a wrapper around linters, not a linter.

It's not its role to define standardized guidance or force a linter to change its implementation, it would be terribly pretentious for golangci-lint to do that: the majority of linters exist outside of golangci-lint.

For example, gofmt or goimports will not change their implementation for us.

The difficulty of maintaining open-source software and the related documentation are very often underestimated by users.

[matrixik]

I'm not saying they need to change implementation, more in like "if you store info about your issues in some way then golangci-lint when including your linter could easily parse it and provide users with full metadata and easily generate (proposed in this issue) linter rules documentation, if not then golangci-lint could try doing it separately for every linter but there could be some missing data". Especially that some unification already started like in https://github.com/mvdan/gofumpt/issues/78.

This could be discussed with some bigger linter maintainers because maybe there could be a way that will make life easier for golangci-lint and them at the same time. Maybe format could be similar with gopls suggested fixes?

I know what it mean to maintain open-source software and docs, I was working on OpenStack Monasca to gather logs and it was a pain when everyone was generating different format of them. That's why Logging Guidelines appeared. They did not force all projects to use this but over time some services started using this guidance and new projects was faster to be handled properly by Monasca.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.