`no-magic-numbers`: allow numbers in expressions
See original GitHub issueNow the rule forbids usage of numbers even when they construct a constant with some expression. F.ex., if we want to correctly set a 2-min timeout value we’ll write something like below getting rule report
const MSEC_PER_SEC = 1000;
const SEC_PER_MIN = 60;
...
const INTRV = 2 * SEC_PER_MIN * MSEC_PER_SEC; // rule complains
What rule do you want to change? no-magic-numbers
Does this change cause the rule to produce more or fewer warnings? fewer
How will the change be implemented? (New option, new default behavior, etc.)? new default behavior
Please provide some example code that this change will affect:
const FOO = 2;
const BAR = 3 * FOO;
What does the rule currently do for this code? 2:13 No magic number 3
What will the rule do after it’s changed? no message
Are you willing to submit a pull request to implement this change? Probably, if the team accepts the request
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
no-magic-numbers - TypeScript ESLint
This rule extends the base eslint/no-magic-numbers rule. It adds support for: numeric literal types ( type T = 1 ),; enum members (...
Read more >no-magic-numbers - Rule
Rule: no-magic-numbers Disallows the use constant number values outside of variable assignments. When no list of allowed values is specified, -1, 0 and...
Read more >[no-magic-numbers] false positives everywhere, totally broken
the point of the no-magic-numbers rule is so that you don't use number values in your code, you should refactor them to constant...
Read more >no-magic-numbers - ESLint - Pluggable JavaScript Linter
'Magic numbers' are numbers that occur multiple times in code without an explicit meaning. They should preferably be replaced by named constants.
Read more >no-magic-number | Dart Code Metrics
no-magic-number. added in: 1.6.0. warning. ⚙️. Warns against using number literals outside of named constants or variables. Exceptions are made for common ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I agree with @anikethsaha that this is exactly what the rule is intended to enforce. In this specific example the
2
doesn’t seem like a magic number because it’s fairly clear what this it’s referring to, but if it were a larger number it would be confusing. For instance, if the code snippet looked like this, I think the rule should warn:Given the above, I’m not sure how the rule would be able to distinguish when a magic number is allowed in an expression and when it isn’t, and should treat all numbers in expressions as magic numbers.
The team has made the difficult decision to freeze stylistic rules (please see https://eslint.org/blog/2020/05/changes-to-rules-policies for more details), and we unfortunately won’t be able to accept this proposal.
Thanks for contributing to ESLint and for being willing to implement your proposal.