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:

• magic number (wikipedia)
• magic number (stack overflow question)

I don't see a huge benefit in nailing down a precise definition of what is, and what is not, a magic number.

Fair enough. My personal criteria is that a number used once, is just a number. Used more than once -- to represent the same value -- it should be a symbolic constant or enum.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.

In the absence of evidence, opinion is indistinguishable from prejudice.

My personal criteria is that a number used once, is just a number. Used more than once -- to represent the same value -- it should be a symbolic constant or enum.

From magic number (wikipedia), some possible exceptions:
• The use of 0 and 1 as initial or incremental values in a loop, such as for (int i = 0; i < max; i += 1)
• The use of 2 to check whether a number is even or odd, as in isEven = (x % 2 == 0)
• The use of 100 to calculate percentages
If 0, 1, 2, 100 in the examples above were used more than once in your program, would you create a symbolic name for them?

You've already got the answer you wanted, but an amusing (to me and one workmate at least, although not amusing to another) example may be appreciated.

A workmate and I were working through refactoring and understanding some code (C++, but not really relevant to the story) that another workmate had written. The code concerned used circular buffers at the end of a calculation chain for feeding samples into a digital to analog converter. Getting the size of the buffer right is a critical part of making the system work correctly. We encountered a few lines that were used to configure the buffers and looked something like:

mOutBuffer = CreateBuffer(baseBufferSize+3*2*k10HzKneeSampleBufferSize
+);
[download]

We couldn't figure out what the 3 * 2 was doing in there and there were no comments to give any clue so we changed it to:

#define PI 3.1415 // Circular buffers

mOutBuffer = CreateBuffer(baseBufferSize + 2 * PI * k10HzKneeSampleBuf
+ferSize);
[download]

which we at least thought amusing. We hoped that the other workmate would appreciate the joke then provide some sort of sensible name for the constant and perhaps a useful comment. Instead, at the next scrum he noted that someone had added a PI constant "probably they thought it was amusing" and it wasn't right!

Sadly the PI constant is still in the code and we still don't really know why that particular value is used. There was no doubt a clue in the value being written as 3 * 2, but it escaped us.

So, that's a classic magic number. It's critical to correct operation of the code, but provides not obvious rational for its selection.

And if you read a little friction in the team between the lines, you are right. The person who wrote that part of the code is very bright, but I think he has trouble appreciating that not everyone understands stuff in the way he does.

Nice example. Thanks.

(Now you've got me sitting here wondering: Is it 2 channels (stereo) and 3 byte (24-bit) samples? And also wondering; did anyone actually ask him :)

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.

In the absence of evidence, opinion is indistinguishable from prejudice.

The code was somewhat faked up because I didn't have access to the details and they don't actually matter much anyway. The code is actually in a multiple channel sampling system used for biological signals. It does sample 24 bits (at around 40 kHz), but most of the signal processing is 32 bits and the final output is 16 bits (at around 120 kHz)! But to satisfy curiosity somewhat the code is currently:

out = new RingBufferEnum(in.get(), 2 * PI * (9*5));
[download]

The 9 is a decimation ratio. I can't remember what the 5 is (maybe an interpolation ratio?), and the 2 * PI is a fudge factor we determined by in essence profiling the code (with a logic analyser actually).

There was extensive discussion around the buffer sizes, but at a higher "philosophical" level that didn't really touch on the magic numbers. Oh and look, here's the original code:

//This somewhat empirical value of 4, in combination with a kMinSample
+sToProcess
//= 16, gives the best performance in the sense of minimizing the like
+lihood of
//DAC buffer underflow and ADC buffer overflow during the period just 
+after
//sampling starting when the filters are initialising.
const int kMultirateInitNumInnerSamples = 2;

...

out = new RingBufferEnum::Enum( in.get(), (9*5) + 5, 9 * 5 * kMultirat
+eInitNumInnerSamples);
[download]

Note the rather worrying disconnect between 4 in the comment and the actual constant value of 2!

The whole exercise was not a shining example of a team pulling together, but the situation was complicated by factors beyond our control.

Premature optimization is the root of all job security