Magic Numbers In Arrays? - C++

I'm a fairly new programmer, and I apologize if this information is easily available out there, I just haven't been able to find it yet.

Here's my question:

Is is considered magic numbers when you use a literal number to access a specific element of an array?

For example:

arrayOfNumbers[6] // Is six a magic number in this case?

I ask this question because one of my pr开发者_StackOverflow社区ofessors is adamant that all literal numbers in a program are magic numbers. It would be nice for me just to access an element of an array using a real number, instead of using a named constant for each element.

Thanks!

---

That really depends on the context. If you have code like this:

arr[0] = "Long";
arr[1] = "sentence";
arr[2] = "as";
arr[3] = "array.";

...then 0..3 are not considered magic numbers. However, if you have:

int doStuff() 
{
   return my_global_array[6];
}

...then 6 is definitively a magic number.

---

It's pretty magic.

I mean, why are you accessing the 6th element? What's are the semantics that should be applied to that number? As it stands all we know is "the 6th (zero-based) number". If we knew the declaration of arrayOfNumbers we would further know its type (e.g. an int or a double).

But if you said:

arrayOfNumbers[kDistanceToSaturn]; 

...now it has much more meaning to someone reading the code.

In general one iterates over an array, performing some operation on each element, because one doesn't know how long the array is and you can't just access it in a hardcoded manner.

However, sometimes array elements have specific meanings, for example, in graphics programming. Sometimes an array is always the same size because the data demands it (e.g. certain transform matrices). In these cases it may or may not be okay to access the specific element by number: domain experts will know what you're doing, but generalists probably won't. Giving the magic index number a name makes it more obvious to those who have to maintain your code, and helps you to prevent typing the wrong one accidentally.

In my example above I assumed your array holds distances from the sun to a planet. The sun would be the zeroth element, thus arrayOfNumbers[kDistanceToSun] = 0. Then as you increment, each element contains the distance to the next farthest planet: mercury, venus, etc. This is much more readable than just typing the number of the planet you want. In this case the array is of a fixed size because there are a fixed number of planets (well, except the whole Pluto debacle).

The other problem is that "arrayOfNumbers" tells us nothing about the contents of the array. We already know its an array of numbers because we saw the declaration somewhere where you said int arrayOfNumers[12345]; or however you declared it. Instead, something like:

int distanceToPlanetsFromSol[kNumberOfPlanets];

...gives us a much better idea of what the data actually is and what its semantics are. One of your goals as a programmer should be to write code that is self-documenting in this manner.

And then we can argue elsewhere if kNumberOfPlanets should be 8 or 9. :)

---

You should ask yourself why are you accessing that particular position. In this case, I assume that if you are doing arrayOfNumbers[6] the sixth position has some special meaning. If you think what's that meaning, you probably realize that it's a magic number hiding that.

---

another way to look at it:

What if after some chance the program needs to access 7th element instead of 6th? HOw would you or a maintainer know that? If for example if the 6th entry is the count of trees in CA it would be a good thing to put

 #define CA_STATE_ENTRY 6

Then if now the table is reordered somebody can see that they need to change this to 9 (say). BTW I am not saying this is the best way to maintain an array for tree counts by state - it probably isnt.

Likewise, if later people want to change the program to deal with trees in oregon, then they know to replace

 trees[CA_STATE_ENTRY]

with

 trees[OR_STATE_ENTRY]

The point is

 trees[6]

is not self-documenting

Of course for c++ it should be an enum not a #define

---

You'd have to provide more context for a meaningful answer. Not all literal numbers are magic, but many are. In a case like that there is no way at all to tell for sure, though most cases I can think of off-hand with an explicit array index >>1 probably qualify as magic.

---

Not all literals in a program really qualify as "magic numbers" -- but this one certainly seems to. The 6 gives us no clue of why you're accessing that particular element of the array.

To not be a magic number, you need its meaning to be quite clear even on first examination (or at least minimal examination) why that value is being used. Just for example, a lot of code will do things like: &x[0]. In this case, it's typically pretty clear that the '0' really just means "the beginning of the array."

---

If you need to access a particular element of the array, chances are you're doing it wrong.

You should almost always be iterating over the entire array.

---

It's only not a magic number if your program is doing something very special involving the number six specifically. Could you provide some context?

---

That's the problem with professors, they're often too academic. In theory he's right, as usual, but usually magic numbers are used in a stricter context, when the number is embedded in a data stream, allowing you to detect certain properties of the stream (like the signature header of a file type for instance). See also this Wikipedia entry.

---

Usually not all constant values in software are called magic numbers. A java class files always starts with the hex value 0xcafebabe a windows .exe file with MZ 0x4d, 0x5a , this allows you quickly (but not for sure) to identify the content of a binary file.

---

In a MISRA compliant system, all values except 0 and 1 are considered magic numbers. My opinion has always been if the constant value is obvious or likely won't change then leave it as a number. If in doubt create a unique constant since long term maintenance will be easier.