Why an unexplained number becomes a maintenance risk
A magic number is a literal value embedded in code without making its purpose clear. Consider a condition such as `if (age > 18)`: the number might represent a legal threshold, a product rule, or merely a temporary choice. The computer can use it, but a future developer has no reliable way to tell what changing it would mean.
That uncertainty matters most when a value sits inside a function that handles several steps or rules. Someone trying to fix one behavior may leave the number untouched because it appears significant—or change it without realizing the same rule is used elsewhere. Either choice can preserve a bug or introduce a new one.
Give the value a name and a home
Replacing the literal with a descriptive constant makes the code state its intent: `MINIMUM_AGE` is easier to interpret than `18`. If the value is part of a business rule, putting it in an appropriate configuration or policy layer can also make clear where the rule belongs and how it should be changed.
A name is not magic by itself. `LIMIT = 18` still leaves questions; a useful name explains what is limited and, where necessary, what units the value uses. A delay of `30` could mean seconds or minutes, while a threshold of `0.1` could represent a fraction or a percentage. Naming and placement supply context the raw number cannot.
Small clarity prevents risky edits
When a rule changes, developers can search for its named constant, inspect the affected behavior, and update it deliberately instead of guessing which matching numbers are related. Tests can then check the rule in terms of its meaning, rather than merely confirming that a particular literal appears in the code.
The payoff is not fewer numbers. It is fewer decisions made in the dark: a future maintainer can see what a value controls before deciding whether it is safe to change.
