"Magic Numbers"

[Peaceblossom]

Hey, long time since I've posted here.

Anyway, I'm taking Computer Science at the University of Calgary and my professor and TA both hate the idea of "magic numbers" in code. They say it would be best to assign a variable a number and use the variable inside my equations.

Anyway, I had nice Python code that looked really very clean for how complex my equations were (evaluating third degree polynomials at different values of x in a range) but I had to shift all my data 400 units in the X direction and 300 units in the Y direction. I simply used (value_a + 300) but my TA mentioned that I shouldn't have these magic numbers.

What I'm getting at is that I assigned a variable Y_SHIFT instead of 300, X_SHIFT instead of 400, and PIXEL_UNIT as 30. Now, my once simple code, is filled with these variables written in all caps and my equations don't fit on one or two lines anymore. My equations are broken up and difficult to read with all these variables replacing my "magic numbers". As it stands, I also have a few numbers still floating around as I want certain things to be shifted 402 units or 398 units instead of the standard 400. so I now have code that looks like "Y_SHIFT + 4" in the middle of my equations.

So I realize that if those numbers ever need to change, it will be very easy to look back at my code and change them, but right now that code is messy to read and work with, but still functions as it should.

I'm wondering if anyone here can attest to specific benefits of creating these variables, or if they use them at all to eliminate so called "magic numbers". Also, if you're all for it, should I create additional ones that have values of 398, 402, etc, or should I just keep my Y_SHIFT + 2 in my equations?

Thanks in advance.

[Cinjection]

I would say that clarity is a more important reason to use named constants instead of magic numbers. Think of a programmer that will have to read your code later. Will they instantly understand the significance of the number 300?

If your lines are too long, you should consider breaking up the calculation into smaller bits. You can store the intermediate bits in variables.

For example, if you were going to calculate the roots of a function using the quadratic equation, you could have one variable that just contains the discriminant. This would make your lines smaller, and your overall function much easier to read.

[RageOfOrder]

The advantage to putting magic numbers into variables is when someone else reads your code (Or you look at it again next year) there will be this nice variable definition at the top that can be commented to explain why it is the value that you chose.

Plus it's easier to change if you need to.

When it's code for myself and nobody else, anything goes.
When it's code that someone else is potentially going to see (Namely assignments...) then use variables for that stuff.

[gumOnShoe]

I agree that its certainly not pretty, but having worked with anything graphical you'll begin to understand when you need to make changes why it can be a good idea.

It is easier to do from the outset than converting your code half way through.....

I do wish there was a better way to to do this and represent it though because the only reason you are actually naming them is to have a "comment" with out having a comment, if you are only using the number in one place...

[AndyPerfect]

I'm going to have to disagree and say that making a variable to switch out the 'magic numbers' makes code tons better. It's the most antagonizing thing to start looking at someone's code and see a += 75 or if (args[0].equals("17")) etc. What in the world is '17'? why are you adding 75? Simply making a variable

private static final int NUMOFCHARS = 17

makes everyone's world so much nicer. All of a sudden, if you want to change that magic '17' to an 18, you don't have to edit tons of lines of code. It's one change. The end.

[Peaceblossom]

At 10/20/09 03:04 AM, AndyPerfect wrote: makes everyone's world so much nicer. All of a sudden, if you want to change that magic '17' to an 18, you don't have to edit tons of lines of code. It's one change. The end.

Yeah, I kind of figured out how to clean my code up a little, and I got this whole variable thing sorted out. I guess breaking up your equations, even if you split it into six or eight smaller ones, still makes them a hell of a lot prettier.

[amaterasu]

...or you could just add a comment above that line of code explaining what the "magic number" is.

problem solved.

[Cinjection]

At 10/20/09 06:43 PM, amaterasu wrote: ...or you could just add a comment above that line of code explaining what the "magic number" is.

problem solved.

Or you can make your code self-documenting. This is considerably more reliable than writing comments that often don't get changed to reflect changing code, and become misleading.

[amaterasu]

At 10/20/09 09:23 PM, Cinjection wrote:

At 10/20/09 06:43 PM, amaterasu wrote: ...or you could just add a comment above that line of code explaining what the "magic number" is.

problem solved.

Or you can make your code self-documenting. This is considerably more reliable than writing comments that often don't get changed to reflect changing code, and become misleading.

Sometimes you use constants that doesn't really get changed. I'm not going to argue with you, its a matter of preference.

[amaterasu]

At 10/21/09 10:52 AM, amaterasu wrote:

At 10/20/09 09:23 PM, Cinjection wrote:

At 10/20/09 06:43 PM, amaterasu wrote: ...or you could just add a comment above that line of code explaining what the "magic number" is.

problem solved.

Or you can make your code self-documenting. This is considerably more reliable than writing comments that often don't get changed to reflect changing code, and become misleading.

Sometimes you use constants that doesn't really get changed. I'm not going to argue with you, its a matter of preference.

Let me rephrase that...sometimes there are literals in code that don't really get changed. Having a comment explaining whatever literals you use in a line of code is acceptable. Constants are definitely good to use, but sometimes they are unnecessary and clutter up code.