-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Add blanket_disable_command rule #4731
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
Add blanket_disable_command rule #4731
Conversation
5cc14a6
to
f370aa7
Compare
16ee74e
to
413da97
Compare
Source/SwiftLintFramework/Rules/Lint/NoBlanketDisablesRule.swift
Outdated
Show resolved
Hide resolved
In general, I like this rule a lot! The OSS findings and the findings in SwiftLint itself splendidly show how much SwiftLint misses it. |
413da97
to
35f25e0
Compare
Thanks! I just saw so many people just disabling stuff for the remainder of the file to fix one warning that it got annoying - we have a custom Danger script to do (some of) this, but much nicer to just have it baked in. And yes, it does seem to get a lot of hits :-) Not entirely sure that |
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.
Indeed, blanket_disable_command
sounds better to me. Also, the wording of the violation messages can be improved. I made a few suggestions. Please let me know what you think.
Source/SwiftLintFramework/Rules/Lint/NoBlanketDisablesRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintFramework/Rules/Lint/NoBlanketDisablesRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintFramework/Rules/Lint/NoBlanketDisablesRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintFramework/Rules/Lint/NoBlanketDisablesRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintFramework/Rules/Lint/NoBlanketDisablesRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintFramework/Rules/Lint/NoBlanketDisablesRule.swift
Outdated
Show resolved
Hide resolved
Cool - I went with |
c88f83f
to
6b52cb2
Compare
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.
Just found some more points I'd like to discuss. Sorry! 😅
Source/SwiftLintFramework/Rules/Lint/BlanketDisableCommandRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintFramework/Rules/Lint/BlanketDisableCommandRule.swift
Outdated
Show resolved
Hide resolved
public private(set) var allowedRuleIdentifiers: Set<String> = ["file_length", "single_test_class"] | ||
public private(set) var alwaysBlanketDisableRuleIdentifiers: Set<String> = [] |
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.
Isn't it the other way around?
public private(set) var allowedRuleIdentifiers: Set<String> = ["file_length", "single_test_class"] | |
public private(set) var alwaysBlanketDisableRuleIdentifiers: Set<String> = [] | |
public private(set) var allowedRuleIdentifiers: Set<String> = [] | |
public private(set) var alwaysBlanketDisableRuleIdentifiers: Set<String> = ["file_length", "single_test_class"] |
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.
This is actually correct - the intention is that by default, the rule will not complain about
// swiftlint:disable file_length
, for example, even though it's not re-enabled, because it makes sense to just disable it once for the whole file, and there's no point in doing // swiftlint:enable file_length
at the end of the file.
Adding a rule to the alwaysBlanketDisableRuleIdentifiers
goes one step further, by warning the user on any SwiftLint command affecting the rule, that is anything other than // swiftlint:disable file_length
. I didn't want to enable that by default.
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 have made one slight modification though - any rules in alwaysBlanketDisableRuleIdentifiers
are automatically "allowed"
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.
Hm, got it ... this is tricky, though.
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 think this is the right behaviour, but maybe the naming isn't quite perfect. I went with allowed_rules
and always_blanket_disable
, but maybe there's something better, although I don't have any good suggestions.
I've also just added file_header
, file_name
, and file_name_no_space
to the default allowed rules list.
Source/SwiftLintFramework/Rules/Lint/BlanketDisableCommandRule.swift
Outdated
Show resolved
Hide resolved
No worries :-) I'll try and get to these today ... |
8f50371
to
7f76874
Compare
ok - so I think I've addressed everything from that last batch :-) |
return violations | ||
} | ||
|
||
private func violation( |
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.
Is this indirection really needed for only one saved conversion?
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.
So in three cases I have a RuleIdentifier (so they use the indirection), and then in two cases, in validateAlwaysBlanketDisable
, I have the string.
I couldn't see anyway round that - the indirection felt cleaner than making the three call sites call stringRepresentation
themselves.
7f76874
to
6455403
Compare
Well done. Thanks @mildm8nnered! |
Adds a new SwiftLint rule:
blanket_disable_command
Resolves #4684
This warns (by default) when a SwiftLint rule is disabled, and then never later re-enabled. In many cases this is because the developer forgot to re-enable the rule, or somehow bodged it (e.g.
// swftlint:enable some_rule
), resulting in stretches of code going unintentionally un-linted.Violations of this rule are surprisingly common. I found a bunch in the SwiftLint source code, which I've patched in various ways in this PR - some could simply be turned into
// swiftlint:disable:next some_rule
's and some I suppressed.There are some rules that it doesn't make sense to re-enable, and that should apply to the whole file. An
allowed_rules
configuration parameter allows these to be specified. By default,file_length
andsingle_test_class
are allowed.For these and possibly other rules, we may want to disable a particular rule always for the entire file, and to warn if it that rule is disabled with a modifier or re-enabled. The
always_blanket_disable
configuration parameter allows a set of rules to be specified that should always be warned on anything except a blanket disable. By default the set is empty.This rule will also warn if you use
swiftlint:disable
to disable a rule that's already disabled, orswiftlint:enable
to enable a rule that isn't disabled.nonTriggeringExamples:
triggeringExamples:
See #4684