realm
Rule Request: no_blanket_disables - disallow disabling SwiftLint rules for the entire file
New Issue Checklist
- [x ] Updated SwiftLint to the latest version
- [ x] I searched for existing GitHub issues
New rule request
- Why should this rule be added?
Sometimes it's necessary to disable a SwiftLint rule in code, with the // swiftlint:disable rule_name directive, but engineers intentionally just put the disable at the top of, and applying to the, the entire file, when only a short stretch of code is relevant.
At other times, developers may intend to re-enable the SwiftLint rule, but forget to do so.
In either case, swiftlint rules can end up being disabled for stretches of code that we actually probably do want to lint.
This rule would warn on any cases of // swiftlint:disable rule_name that do not have a matching enable before the end of the file.
- Provide several examples of what would and wouldn't trigger violations.
Triggering examples:
// swiftlint:disable some_rule
// swiftlint:disable some_rule some_other_rule
// swiftlint:enable some_rule
Non-triggering examples:
// swiftlint:disable some_rule
// swiftlint:enable some_rule
// swiftlint:disable some_rule some_other_rule
// swiftlint:enable some_rule
// swiftlint:enable some_other_rule
// swiftlint:disable:this some_rule
// swiftlint:disable:previous some_rule
// swiftlint:disable:next some_rule
- Should the rule be configurable, if so what parameters should be configurable?
For some rules, such as file_length it doesn't make sense to reenable them.
An allowed_rules parameter would specify rules that will be ignored by this rule.
- Should the rule be opt-in or enabled by default? Why? See README.md for guidelines on when to mark a rule as opt-in.
opt-in, as users should never really want to disable rules for irrelevant stretches of code.
