[platform] Codify naming multi-line conditions - #156
Merged
Conversation
Temporary violation, removed in the next commit once CI has shown the rule catches it. SwiftLint is not installed locally, so CI is the only place the rule can be exercised — and a green run would otherwise prove only that the config parses, not that the regex matches anything.
CI showed the rule firing on it, with the intended message:
RuleProbe.swift:4:1: error: Named Multiline Condition Violation: Name a
multi-line condition — `let isThing = a && b`, then `if isThing {`
which is what the probe was for. The rule itself is the change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a SwiftLint custom rule for the shape we settled on in #155: a condition long enough for SwiftFormat to wrap is long enough to deserve a name.
// flagged if output.isEmpty, outputtable is FormatComponent, parts.last?.isSeparator == true { // wanted let isStrandingSeparator = output.isEmpty && … if isStrandingSeparator {Scoped to
ifonly — the multi-lineguard … else { return }form appears across five files and reads fine, so it is untouched. No existing file inSourcesorTestsmatches, so nothing is retroactively broken.The first commit deliberately violates the rule. SwiftLint isn't installed on my machine, so CI is the only place the rule can be exercised, and a green run would prove only that the YAML parses — not that the regex matches anything. A rule which silently never fires is worse than no rule, since it reads as enforcement. So: lint failing on the probe commit is the passing result, then the probe comes out and lint goes green.
🤖 Generated with Claude Code