Rule Change: Treat class / instance fields as named constants in no-magic-numbers
See original GitHub issueWhat rule do you want to change?
no-magic-numbers
What change to do you want to make?
Generate fewer warnings
How do you think the change should be implemented?
A new default behavior
Example code
class Foo {
static bar = 1;
baz = 2;
}
What does the rule currently do for this code?
Shows these two errors:
No magic number: 1
No magic number: 2
What will the rule do after it’s changed?
Show no errors.
Participation
- I am willing to submit a pull request to implement this change.
Additional comments
No response
Issue Analytics
- State:
- Created a year ago
- Reactions:2
- Comments:11 (9 by maintainers)
Top Results From Across the Web
Rule Change: Treat class / instance fields as named constants in no ...
Solves #16228 by extending the non-error case to PropertyDefinition if parent.parent 's type is a ClassBody . Note that the inner enforceConst check...
Read more >What is a magic number, and why is it bad? - Stack Overflow
In programming, a magic number is an embedded numerical constant that appears without explanation. If it appears in two distinct locations, it can...
Read more >Replace Magic Number with Symbolic Constant
Problem: Your code uses a number that has a certain meaning to it. Solution: Replace this number with a constant that has a...
Read more >Python Constants: Improve Your Code's Maintainability
In programming, the term constant refers to names representing values that don't change during a program's execution.
Read more >Reading 4: Code Review
Variables 1/1 ... Designed to accommodate change without rewriting. ... of these rules, at least the ones that are relevant at this point...
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 FreeTop 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
Top GitHub Comments
I’ll champion this.
I think the best solution is to add a new option:
ignoreClassFieldInitialValues
(defaultfalse
to keep the current default behavior).I think that it makes sense that
detectObjects
applies to assignments - but declarative things like class fields have a name, and aren’t being dynamically assigned, so i’d expect them to be accepted by default.