-
-
Notifications
You must be signed in to change notification settings - Fork 5.9k
enforce nolint scope #34851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
enforce nolint scope #34851
Conversation
all with the same reason
scope condition one for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work. Resolve comments above before merge.
@@ -10,9 +10,9 @@ import ( | |||
) | |||
|
|||
func TestCleanUploadFileName(t *testing.T) { | |||
assert.Empty(t, CleanGitTreePath("")) | |||
assert.Empty(t, CleanGitTreePath(".")) | |||
assert.Equal(t, "", CleanGitTreePath("")) //nolint:testifylint // for readability and alignment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, adding comments make it harder to read ...
I can help to rewrite the code to something like
for testCase := range cases {
assert.Equal(....)
}
(if you don't mind)
Then we can get rid of the "nolint" tricks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Go ahead, the maintainer edit thing is checked :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, eliminating nolints is better. I think something ought to be done about the migration packages too. Maybe just a config in .golangci.yml
that disables revive for those files, but it's a pretty broad disable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those are fixable with a rename. I don't suppose that's breaking as migrations are internal and I'd be surprised if something in our code relied on package name. It's more of an issue of what name should there be.
There's also not much benefit in that and the _
rule could be suppressed globally (to cover oauth_*
as well) or for migrations only.
See text based rules which I think would work for this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which specific revive rule is being triggered by these underscores? Maybe we can disable the rule itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
var-naming: don't use an underscore in package name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd vote for disabling var-naming
completely. This is the kind of rule I don't want to have because it's stylistic. Focus of linting should be primary in finding bugs, not style issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, just disabling package name checks should also work:
linters:
settings:
revive:
rules:
- name: var-naming
arguments:
- skip-package-name-checks: true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe better overall to disable var-naming completely. @TheFox0x7 would you like to do it in this PR or we merge this and do it in another.
Made some changes:
|
enable nolintlint scope requirement
add comments to new directives so it's more obvious why they are in place
I can also toggle the mandatory comments on if that's something of interest.