feat: add usestdlibvars

[sashamelentyev]

A linter that detect the possibility to use variables/constants from the Go standard library.
https://github.com/sashamelentyev/usestdlibvars

[kamilsk]

Did you check context?

I see only WriteHeader, https://github.com/sashamelentyev/reusestdlibvars/blob/d020ba07af78c4220a075d568803909cdc7d81c1/pkg/analyzer/analyzer.go#L30-L63. What about time' constants https://pkg.go.dev/time#pkg-constants, enums https://pkg.go.dev/time#Month, etc

What about http.MethodGet, etc.?

[sashamelentyev]

Yes, I check func name WriteHeader, and check arg type for this func

[sashamelentyev]

What about http.MethodGet, etc.?

Month - added already

I plan add more to next version. And after lint add to golangci-lint list

[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.
• The linter repository must have a CI and tests.
• 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 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.

[ldez]

My current opinion: the linter needs to have a larger scope, currently this is too limited.
Also, I think that the amount of false-positive can be really important.

[sashamelentyev]

@kamilsk @ldez added http method and time layouts.
In http method case - checks only funcs NewRequest and NewRequestWithContext

[sashamelentyev]

Added full list of HTTP status codes

[ldez]

just a remark, for me, it's not "reuse" (reusestdlibvars) but "use" (usestdlibvars).

For me, "reuse" means "use again".

[sashamelentyev]

I rename lint right now

[ldez]

Some remarks about the implementation:

• variable names that start with _ are not Go idiomatic.
• the constants are hard-coded manually, this is a bit weak, you can either generate the code or use reflect or at least use the constants themself.
• the multiple calls to i.Preorder are useless and will impact the performance: use only one Preorder with a filter with several node types and a switch on the type of the node.

[sashamelentyev]

@ldez all done! Thank you for review!

[sashamelentyev]

@ldez please help me with function description here and here

[ldez]

The problem is not the description but the code, I will try to open a PR

[ldez]

Note: there is an already existing rule about HTTP status code inside staticcheck.

https://staticcheck.io/docs/checks/#ST1013

[sashamelentyev]

@ldez added settings

[sashamelentyev]

@ldez what need to do for merge?

[ldez]

I need time.

[sashamelentyev]

@ldez, forgive me for push, thank you for all what you do

[sashamelentyev]

Added default RPC path and struct elements checker (http.Request & http.Response case)

[ldez]

LGTM