SwiftLint
SwiftLint copied to clipboard
Rule Request: No magic number
New Issue Checklist
- [x] Updated SwiftLint to the latest version
- [x] I searched for existing GitHub issues
New rule request
Please describe the rule idea, format
this issue's title as Rule Request: [Rule Name]
and describe:
-
Why should this rule be added? Share links to existing discussion about what the community thinks about this. https://eslint.org/docs/latest/rules/no-magic-numbers
-
Provide several examples of what would and wouldn't trigger violations.
Basically, when you use a number without giving it some context.
Circle()
.fill(Color.primary.opacity(isAnimate ? 0.1 : 1.0 )) // magic numbers
.frame(
width: 10, // magic number
height: 10
)
-
Should the rule be configurable, if so what parameters should be configurable? No
-
Should the rule be opt-in or enabled by default? Why?
It should be optional
This is a good idea. One small comment, I think you should edit the title to Rule Request: No magic number
to comply with the template
This is a good idea. One small comment, I think you should edit the title to
Rule Request: No magic number
to comply with the template
Done! Thanks
About item 4: what do you think of having a configuration to allow some numbers? 0 and 1 are so common and understandable that this rule without configuration may trigger false positives. Examples:
- It's common to do
array[0]
to access the first element. Without this option, one would need to define alet firstIndex = 0
just to doarray[firstIndex]
. Less readable than just usingarray[0]
. - In the case of 1, it's common to have some operation plus or minus 1 to avoid off-by-one errors. Having to define another constant may make the code more unreadable.
Using that link you provided as an example, eslint accepts an array of ignored numbers. That way, you can have a rule no-magic-numbers ignore:[0,1]
About item 4: what do you think of having a configuration to allow some numbers? 0 and 1 are so common and understandable that this rule without configuration may trigger false positives.
Alternatively, 0 and 1 could just be ignored by default since they are so widely used in all kinds of contexts. Same for 0.0 and 1.0 probably. A configuration to ignore arbitrary numbers in a whole project or a subset of files might not turn out to be very useful. Why would someone like to ignore "57", for example? That said, I would not make the rule configurable at first until someone comes up with a very good example showing that it's really necessary.
Should be closed since no_magic_numbers
is already implemented in #4265 ~