Rule Request: Preprocessor flag statements inequality check
Nobody has claimed this yet.
- Dominant language
- Swift
- Stars
- 19.7k
- Forks
- 2.3k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 11
Description
New Issue Checklist
- Updated SwiftLint to the latest version
- I searched for existing GitHub issues
New rule request
For code that is controlled via preprocessor flags (#if DEBUG etc.), an error/warning should appear if all statements embedded in flag check are equal.
1. Why should this rule be added?
Such a check can prevent unexpected runtime behavior if the app doesn't have unit and/or UI tests implemented.
2. Provide several examples of what would and wouldn't trigger violations.
Triggering examples:
static let shouldShowDebugMenu: Bool = {
#if DEBUG
return true
#else
return true ↓
#endif
}()
var environment: String {
#if DEBUG
return "Debug"
#elseif BETA
return "Debug" ↓
#else
return "Debug" ↓
#endif
}
var isPrerelease: Bool {
#if DEBUG || BETA
return true
#else
return true ↓
#endif
}
let viewController: UIViewController
#if MOCKING
viewController = FooViewController()
#else
viewController = FooViewController() ↓
#endif
Non-triggering examples:
static let shouldShowDebugMenu: Bool = {
#if DEBUG
return true
#else
return false
#endif
}()
var environment: String {
#if DEBUG
return "Debug"
#elseif BETA
return "Beta"
#else
return "Production"
#endif
}
var isPrerelease: Bool {
#if DEBUG || BETA
return true
#else
return false
#endif
}
let viewController: UIViewController
#if MOCKING
viewController = FooViewController()
#else
viewController = BarViewController()
#endif
3. Should the rule be configurable, if so what parameters should be configurable?
I can't imagine any options, apart from warning/error level.
4. Should the rule be opt-in or enabled by default? Why?
Preprocessor flag checks are hard to catch unless there are unit or UI tests in the project running on different environments. I would say this should be enabled by default since it prevents runtime issues, potentially affecting production environments.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are named. Start by locating SwiftLint's existing rule implementations and preprocessor-related tests, then compare them with the triggering and non-triggering examples in this issue. Done means the rule detects equivalent branches, handles the shown conditional forms, and has coverage for both triggering and non-triggering cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100