If neither of these benefits seem worth it to you, I recommend turning off that particular warning on your linter.
#The magic number update
Alternatively, we could use our constant to update it once in both places: PI = 3.14159 If for some reason we decided we wanted pi to a few more decimal places, we would have to update it twice, once for each method. For example, imagine if we had both a circle area method and a circle circumference method: def area_of_circle(radius: float) -> float:ĭef circumference_of_circle(radius: float) -> float: A nice consequence of following DRY is creating a single point of control where a magic number can be changed as needed.
#The magic number code
Under this principle, you try to limit duplication of code (e.g., by not using the same magic number multiple times). Second, another major benefit of removing magic numbers is inadvertently following the Don’t Repeat Yourself (DRY) principle. This will save you time in the future when you inevitably have to make sense of your own code. Numbers can have many meanings which can be cleared up with a simple name. Let me take a moment to try to convince you of the benefits.įirst, as mentioned already, one of the major benefits of removing magic numbers from your code is readability. Given how trivial the examples were in this article, you might conclude that addressing magic numbers is a waste of time. In this case, we stored the value of 3.14 in a constant named PI. The trick is to take the seemingly random value and give it some context by providing it a name. To get rid of the magic number, we need to make a constant for it: PI = 3.14ĭef area_of_circle(radius: float) -> float: The problem as already discussed is that 3.14 is a magic number. In our previous example, we had a method which computed the area of a circle given some radius: def area_of_circle(radius: float) -> float: Therefore, we should find ways to remove them from our code whenever possible.
That said, given how bad our brains are at holding information in short term memory, we should really be trying to leave as little as possible to inference.Īs a result, a magic number is considered bad practice because it makes code harder to reason about. Surely, a lot of folks know the area formula for a circle or the value of pi, so they could probably figure it out from context. In other words, it seemingly spawned from nothing. It’s a problem because it’s not exactly clear what purpose 3.14 serves in our calculation. In this example, our approximation of pi is what would be considered a magic number. For example, we might be computing the area of a circle with an approximation of pi as follows: def area_of_circle(radius: float) -> float:
In short, a magic number is a numerical value (typically excluding 0 and 1) that has an unclear purpose. After all, nothing about programming is magic, though it can feel like it sometimes, so what’s the big deal? Without context, that term is pretty weird. 4 The Power of Best Practices Introducing Magic NumbersĬhances are you’ve found yourself here because a nice static analysis tool like a linter told you your code contains a magic number.
0 kommentar(er)
