Skip to content
This repository was archived by the owner on May 9, 2021. It is now read-only.

explicit var types that can be inferred shouldn't be disallowed #392

Closed
Tracked by #300
willfaught opened this issue Apr 5, 2018 · 3 comments
Closed
Tracked by #300

explicit var types that can be inferred shouldn't be disallowed #392

willfaught opened this issue Apr 5, 2018 · 3 comments

Comments

@willfaught
Copy link

See golang/go#22918.

Basically, this rule doesn't seem to be based on anything in Effective Go or CodeReviewComments.

@warrenstephens
Copy link

I get the should omit type... from declaration of... it will be inferred from the right-hand side message often.

I like having the explicit type next to the var (typically a struct) because it allows my editor to pop-up the internal definition of the struct -- it will not do so otherwise.

In general I like allowing so-called "extraneous" things in source code. Source code is for humans. The parser will always understand valid code. So a behavior that basically says "the parser doesn't need this" is favoring the wrong user of the source code -- i.e. not the human one.

@asciifaceman
Copy link

I never actually noticed this before until I wrote c# only for a few weeks, then coming back to go I was typing everything and the linter complained. I saw a previous issue where a maintainer said it was to prevent this:

var m map[string]int = map[string]int{ ... }

However they didn't explain why this is bad, which is confusing to me as that is expected in other stronger-typed languages.

I may just be off base from language jumping.

@mvdan
Copy link
Member

mvdan commented May 8, 2021

Thank you for submitting this issue! As per golang/go#38968, we are freezing and deprecating golint. There's no drop-in replacement to golint per se, but you should find that Staticcheck works well in encouraging good Go code, much like golint did in the past, since it also includes style checks. There's always gofmt and go vet too, of course.

If you would like to contribute further, I'd encourage you to engage Staticcheck's issue tracker or look at vet's open issues, as they are both actively maintained. If you have an idea that doesn't fit into either of those tools, you could look at other Go linters, or write your own - these days it's fairly straightforward with go/analysis.

To help avoid confusion, I'm closing all issues before we freeze the repository. If you have any feedback, you can leave a comment on the proposal thread where it was decided to deprecate golint - though note that the proposal has been accepted for nearly a year. Thanks!

@mvdan mvdan closed this as completed May 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants