You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Interesting. I'm aware of the common practice to include that comment in generated files. I wasn't aware that linters should exclude those files though. TIL.
Looking at golangci-lint's configuration it appears many of the linters offer analyzing generated code as an option, but as you suggest, it is a flag that can be enabled or disabled. Although, it also looks like golangci-lint excludes generated code files by default at the top-level across all linters by simply excluding any issues found in them, so adding a flag is probably not necessary.
So far gochecknoglobals has been zero configuration, and folks who need more knobs use tools like golangci-lint that offer the additional knobs, and wrap gochecknoglobals and the many other linters available. I'm inclined to keep it as zero configuration unless there's strong need for configuration.
@benjivesterby Are you using golangci-lint? If you are, and you have gochecknoglobals enabled, it shouldn't report generated code files since golangci-lint will exclude any issues found on them by default. If it isn't, we should investigate that.
I'm using golangci-lint for some projects but not the one I'm running this on. It seemed like this was a missing feature other linters have which is why I submitted the issue.
I think I'm inclined to add a flag like -t. The way -t works is it ignores tests by default and adding -t enables tests. So if we add a flag like -g, change the default to ignore generated files, and then when -g is specified we check generated files.
Activity
leighmcculloch commentedon Dec 4, 2021
Interesting. I'm aware of the common practice to include that comment in generated files. I wasn't aware that linters should exclude those files though. TIL.
My experience with other linters, such as
staticcheck, is that generated files are still processed. For example, in this other project I work on that uses staticcheck we had to include these linter comments to disable certain rules: https://github.com/stellar/go/blob/aa089ae/xdr/xdr_generated.go#L1-L2.Looking at golangci-lint's configuration it appears many of the linters offer analyzing generated code as an option, but as you suggest, it is a flag that can be enabled or disabled. Although, it also looks like golangci-lint excludes generated code files by default at the top-level across all linters by simply excluding any issues found in them, so adding a flag is probably not necessary.
So far gochecknoglobals has been zero configuration, and folks who need more knobs use tools like golangci-lint that offer the additional knobs, and wrap gochecknoglobals and the many other linters available. I'm inclined to keep it as zero configuration unless there's strong need for configuration.
@benjivesterby Are you using golangci-lint? If you are, and you have gochecknoglobals enabled, it shouldn't report generated code files since golangci-lint will exclude any issues found on them by default. If it isn't, we should investigate that.
benjivesterby commentedon Dec 4, 2021
I'm using golangci-lint for some projects but not the one I'm running this on. It seemed like this was a missing feature other linters have which is why I submitted the issue.
leighmcculloch commentedon Jan 15, 2023
I think I'm inclined to add a flag like
-t. The way-tworks is it ignores tests by default and adding-tenables tests. So if we add a flag like-g, change the default to ignore generated files, and then when-gis specified we check generated files.Thoughts anyone?