-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Custom Whitelist for Magic Numbers (PLR2004) #10009
Comments
This would indeed be a very nice improvement. I think there are quite a few common magic variables that are commonly ok but inconvenient to define globally (in my case 0.5) and I can imagine users wanting to be able to add any number of additional options. |
I think it's also worth asking whether we should just add 2 and 2.0 to the allowed list? |
I hope this can be made configurable. I use the magic numbers 90, 180, 270, and 360 all over my code, but it wouldn’t make sense to add those to the allowed list for everyone. |
To me it would make sense to both make it configurable, but also add 2/2.0 to the default list of allowed values. |
I agree with the idea that a whitelist for magic numbers should be customizable. The idea of not using magic numbers is because it's harder to infer the meaning of a line of code if random values are sprinkled throughout it. However, depending on the codebase some numbers might make total sense. For example, I work on an energy related application. The number 3600 is commonly used to convert between Joule and kWh. Everyone in our team understands the meaning and context of these numbers and there is no value in making a variable for it first. As @dscorbett described, if you're working with angles (degrees) than 90, 180, 270, and 360 are completely self explanatory. |
PLR2004 has a few whitelisted numbers including '', 0, and 1. #9964 has fixed a bug so that 0.0 and 1.0 are also whitelisted. There is already an option to ignore certain types of variables from the check. I'd like to request an option to extend the whitelist. For example, I have a library where 2 (and 2.0) are really common and I don't want to use a global variable for it. So I ether need many noqa comments or to disable the check entirely.
The text was updated successfully, but these errors were encountered: