Skip to content

Recognise Color and NSColor in no_magic_numbers - #6870

Open
lechuckcaptain wants to merge 1 commit into
realm:mainfrom
lechuckcaptain:no-magic-numbers-color-types
Open

Recognise Color and NSColor in no_magic_numbers#6870
lechuckcaptain wants to merge 1 commit into
realm:mainfrom
lechuckcaptain:no-magic-numbers-color-types

Conversation

@lechuckcaptain

@lechuckcaptain lechuckcaptain commented Aug 10, 2026

Copy link
Copy Markdown

Fixes #6869.

no_magic_numbers exempts the color components of a UIColor initializer, but the check hardcoded that one type name, so SwiftUI's Color and AppKit's NSColor got no exemption at all.

  • Match all three type names, plus module-qualified spellings such as SwiftUI.Color.
  • Accept the opacity label alongside alpha, since SwiftUI spells it differently.

Every literal is still judged by its own label, and the type name must match exactly, so DesignSystem.Color(red: 0.5, …) and UIColor(rgb: 0x33373A, …) stay reported. There are triggering examples pinning both.

Two follow-ups, kept out of this PR to keep it small: the AppKit color-space labels such as srgbRed, which is the second symptom in #6869, and components written as computations such as 0x19 / 255. Both are ready and I will raise them once this lands.

This replaces #6841, which bundled all three changes together.

`no_magic_numbers` exempts the color-component arguments of a `UIColor`
initializer, but the check hardcoded that one type name. SwiftUI's `Color` and
AppKit's `NSColor` got no exemption at all, so their components were reported as
magic numbers.

Match all three type names, and accept module-qualified spellings such as
`SwiftUI.Color`. Accept the `opacity` label alongside `alpha`, since SwiftUI
spells it differently.

Every literal is still judged by its own label, and the type name must match
exactly: `DesignSystem.Color(red: 0.5, …)` and `UIColor(rgb: 0x33373A, …)` stay
reported.
@SwiftLintBot

Copy link
Copy Markdown
1 Warning
⚠️ This PR may need tests.
29 Messages
📖 Building this branch resulted in a binary size of 28461.05 KiB vs 28460.51 KiB when built on main (0% larger).
📖 Linting Aerial with this PR took 0.13 s vs 0.13 s on main (0% slower).
📖 Linting Alamofire with this PR took 0.13 s vs 0.13 s on main (0% slower).
📖 Linting Brave with this PR took 0.56 s vs 0.55 s on main (1% slower).
📖 Linting Brigade with this PR took 1.01 s vs 1.02 s on main (0% faster).
📖 Linting DuckDuckGo with this PR took 2.43 s vs 2.36 s on main (2% slower).
📖 Linting Firefox with this PR took 0.91 s vs 0.91 s on main (0% slower).
📖 Linting Kickstarter with this PR took 0.55 s vs 0.56 s on main (1% faster).
📖 Linting Moya with this PR took 0.09 s vs 0.09 s on main (0% slower).
📖 Linting NetNewsWire with this PR took 0.25 s vs 0.24 s on main (4% slower).
📖 Linting Nimble with this PR took 0.1 s vs 0.1 s on main (0% slower).
📖 Linting PocketCasts with this PR took 0.73 s vs 0.73 s on main (0% slower).
📖 Linting Quick with this PR took 0.1 s vs 0.09 s on main (11% slower).
📖 Linting Realm with this PR took 0.34 s vs 0.34 s on main (0% slower).
📖 Linting Sourcery with this PR took 0.17 s vs 0.17 s on main (0% slower).
📖 Linting Swift with this PR took 0.37 s vs 0.37 s on main (0% slower).
📖 Linting SwiftLintPerformanceTests with this PR took 3.83 s vs 3.79 s on main (1% slower).
📖 Linting VLC with this PR took 0.22 s vs 0.22 s on main (0% slower).
📖 Linting Wire with this PR took 1.13 s vs 1.14 s on main (0% faster).
📖 Linting WordPress with this PR took 0.74 s vs 0.74 s on main (0% slower).
📖 This PR fixed a violation in Aerial: /Aerial/Source/Views/PrefPanel/DisplayView.swift:62:51: Warning: Magic numbers should be replaced by named constants (no_magic_numbers)
📖 This PR fixed a violation in Aerial: /Aerial/Source/Views/PrefPanel/DisplayView.swift:63:47: Warning: Magic numbers should be replaced by named constants (no_magic_numbers)
📖 This PR fixed a violation in Aerial: /Aerial/Source/Views/PrefPanel/DisplayView.swift:69:51: Warning: Magic numbers should be replaced by named constants (no_magic_numbers)
📖 This PR fixed a violation in Aerial: /Aerial/Source/Views/PrefPanel/DisplayView.swift:70:47: Warning: Magic numbers should be replaced by named constants (no_magic_numbers)
📖 This PR fixed a violation in Aerial: /Aerial/Source/Views/PrefPanel/DisplayView.swift:166:47: Warning: Magic numbers should be replaced by named constants (no_magic_numbers)
📖 This PR fixed a violation in Brave: /ios/brave-ios/App/BraveWidgets/LockScreenFavoriteWidget.swift:128:26: Warning: Magic numbers should be replaced by named constants (no_magic_numbers)
📖 This PR fixed a violation in Brave: /ios/brave-ios/Sources/BraveWallet/Crypto/TransactionConfirmations/SaferSignTransactionView.swift:187:41: Warning: Magic numbers should be replaced by named constants (no_magic_numbers)
📖 This PR fixed a violation in Brave: /ios/brave-ios/Sources/BraveWallet/Crypto/Accounts/AccountsView.swift:303:30: Warning: Magic numbers should be replaced by named constants (no_magic_numbers)
📖 This PR fixed a violation in Brave: /ios/brave-ios/Sources/BraveWallet/Crypto/Onboarding/OnboardingNetworkSelectionView.swift:393:32: Warning: Magic numbers should be replaced by named constants (no_magic_numbers)

Generated by 🚫 Danger

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

no_magic_numbers flags the color components of Color and NSColor

2 participants