Linter suggests using reserved words for variable names #393
Comments
|
There will always be instances where the linter falls down and provides a suggestion that can't be implemented. From what I've seen, |
|
Why will there always be instances like that? Wouldn't it be trivial to add a list of reserved words to the linter? Maybe I'm wrong but I think the linter should always try to tell its user what the most common convention is. Do you think a PR to add this functionality would be accepted? |
|
Sure. Feel free to submit one. |
|
Posting this in case anyone wants to submit their own solution or fix my PR; Unfortunately I found out my PR currently has a small error (missing %s in a printf I think - ironically I bet there was a linter warning for that), and I probably won't have time to fix it and test it properly for a while. |
In some circumstances the programmer is tempted to use a Go reserved keyword as a name. A common ofender is the word "type". The Go compiler will not accept that, of course. In those situations a common strategy is to append an underline to the keyword, in order to make the compiler happy. Thus, the name "type" would be changed to "type_" and so on. The golint considered that use of underline as bad style and was wrongly suggesting as a corrective action to employ the original keyword as name. This CL changes golint so that it doesn't make such invalid suggestion. Fixes golang#393
|
I submitted a PR that changes slightly the behavior of golint when it removes the underscores from a name to create a valid name. If the resulting new name is a Go keyword, golint no more suggests the replacement, instead it considers the original code valid. |
In some circumstances the programmer is tempted to use a Go reserved keyword as a name. A common ofender is the word "type". The Go compiler will not accept that, of course. In those situations a common strategy is to append an underline to the keyword, in order to make the compiler happy. Thus, the name "type" would be changed to "type_" and so on. The golint considered that use of underline as bad style and was wrongly suggesting as a corrective action employing the original keyword as name: astVarRef.go:6:2: don't use underscores in Go names; struct field type_ should be type cmdIf.go:32:3: don't use underscores in Go names; var goto_ should be goto This CL changes golint so that it doesn't make such invalid suggestion. Fixes golang#393
|
Still not fixed. I want to use type; but of course I cannot use it as a variable name. What is a standard solution for this? |
In some circumstances programmers are tempted to use Go reserved keywords as names. A common offender is the word "type". The Go compiler will not accept that. In those situations a common strategy is to append an underline to the keyword in order to make the compiler happy. Thus changing the name "type" to "type_". Previously golint considered that use of underline bad style and wrongly suggested employing the original keyword instead: astVarRef.go:6:2: don't use underscores in Go names; struct field type_ should be type cmdIf.go:32:3: don't use underscores in Go names; var goto_ should be goto This CL changes golint so that it doesn't make that invalid suggestion. Fixes golang#393
In some circumstances, programmers are tempted to use Go reserved keywords as names (e.g. "type" or "default"). As this is forbidden in Go, the compiler will reject it. A common workaround is to append an underline to the keyword to make the compiler happy, e.g., changing the name "type" to "type_". Previously golint considered that use of underline bad style and wrongly suggested employing the original keyword instead: astVarRef.go:6:2: don't use underscores in Go names; struct field type_ should be type cmdIf.go:32:3: don't use underscores in Go names; var goto_ should be goto This CL changes golint so that it doesn't make that invalid suggestion. Fixes golang#393
|
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 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! |
One of the parameters for a function I made is called
type_, because "type" is a reserved word.I'm not sure what the convention should be when the name you want to use happens to be a reserved word, but the linter suggests that it should be
type, which isn't a valid variable name.The text was updated successfully, but these errors were encountered: