I don't see a huge benefit in nailing down a
precise definition of what is, and what is not,
a magic number.
We don't have hard and fast rules about magic numbers at work.
Zero and one, for example, will usually survive a code review
(though perhaps not if used with bools).
There is room for common sense, negotiation and programmer discretion.
The focus is on simplicity, clarity and maintainability.
For example, a magic number like 7.4269 that may change in the future
being sprinkled all over the place would not survive the review;
you'd be asked to choose a meaningful name for it,
$customer_interest_rate for example.
Even if the number is PI, and so won't ever change,
the code will usually be clearer if you use $pi
rather than 3.14159.
To be honest, I don't feel strongly about magic numbers
and can't ever remember them being a big issue during a code review.
There are bigger fish to fry, things like:
- Is the component testable in isolation?
- Is the component interface well-designed?
- Has the programmer gone berserk with unnecessary cleverness?
- Is there a coherent error handling policy?
- Are there gaping security violations?
- Is the program easy to support and troubleshoot remotely?
Obligatory references: