'100' is a magic number

Question

Magic numbers are bad... I totally agree. But there's one magic number I find hard to fix:

'100' is a magic number.

Consider this code:

public double getPercent(double rate) {
    return rate * 100;
}

public double getRate(double percent) {
    return percent / 100;
}

SonarQube will raise 2 violations, one for each use of 100. I could replace 100 with a constant variable, but what would be a good name for it? Is that really a good idea? If somebody ever changes its value that will be a disaster. I could also just add // NOSONAR to all the lines that use 100.

What is the best practice for dealing with the magic number 100?

---

UPDATE

From the answers, the most useful bit for me was this:

Practical Magic Number rule: A literal is a not a magic number if the most meaningful variable name for it is the same as the spoken name of the literal.

So by this logic, 100 is NOT a magic number.

However, to make the violation go away, I decided to replace the 100 with a constant:

public static final double HUNDRED = 100;  // change it and I'll kill you

In my real project there are many lines using 100, and if I put // NOSONAR on all those lines that might cover up other potential problems that other developers might inadvertently add later.

Not sure if there will be any real benefits using this constant. A small one may be that when I do git grep 100 I see a lot of matches from resource files in the project, while git grep HUNDRED turns up just the the Java code that uses this.

Answer 1

Speaking as a human programmer (i.e. I am not Lint software), your use of "100" there looks fine to me.

Wikipedia has an article (without citations) titled Accepted limited use of magic numbers: IMO your "100" is in the same category as these other "accepted" magic numbers.

---

This Wiki describing magic numbers says two things.

Firstly,

Practical Magic Number rule: A literal is a not a magic number if the most meaningful variable name for it is the same as the spoken name of the literal.

That's applicable here: you're looking for a named constant like HUNDRED or CENTUM.

Secondly, it also suggests loading "magic" numbers (e.g. a "discount rate") from a configuration file:

static final double DISCOUNT_PERCENT = getProperty( "sales.discount_percent" );
static final double DISCOUNT_FACTOR = 1 - (DISCOUNT_PERCENT / 100);

// ...

salePrice = DISCOUNT_FACTOR * regularPrice;

Note that though this example code carefully loaded DISCOUNT_PERCENT from a configuration, the "100" used to calculate the DISCOUNT_FACTOR is hard-coded.

---

If you use "100" instead of HUNDRED, it's easier for a programmer to understand, and to verify that it's correct.

IMO the only benefit to using HUNDRED is to find the several methods which use the same magic number (in your example it's used by getPercent and getRate).

Answer 2

Although 100 should be fine in source-code, I'm surprised nobody has offered the most readable alternative yet. This should be acceptable for both humans and lint-code:

Define your constant PERCENT=0.01.

Then, when you need to do a conversion:

rate = discount*PERCENT

or

discount = rate/PERCENT

This can completely eliminate your short functions (which are, indeed, trivial). You could have additional constants PERMILLE, PPM, PPB, etc., and it should be obvious for humans what is happening.

Answer 3

Some numbers are called 'magic' because it is unclear where they come from. I think in this particular case, it is clear that 100 originates from the definition of percent. However, if you wish you can define a constant PERCENTS_IN_UNIT_RATE=100 instead of using it directly.

Violations reported by code analysis tools are really only suggestions and it is okay to disagree with them. If in doubt ask other programmers who work on the same project, or toss a coin and move to the next task! :-)

Answer 4

I am on the fence about the 100 being a named constant or not.

I habitually make magic numbers named constants, but not all the time.... it is not unusual for me to have constants called HUNDRED or MILLION. I also regularly have trivial numbers as magic-number constants ....

But, in this case, and what I particularly want to draw attention to, is that your value should be a floating-point, not an integral value.

When you have constants they should be in the most convenient form for users to understand. For example, your value 100 should really be 100.0 which makes the fact that it is a double value obvious.

Answer 5

Others have already stated why they believe that 100 is an acceptable constant here. This answer shows how you can get Sonar to accept that.

Under your-sonar-domain/profiles/, you can edit quality profiles, and the rules in them. The "Magic Number" rule is customisable, you can specify certain numbers for the rule to ignore. Simply specify "100" as a number to ignore.

Answer 6

It technically is since both those 100's have the same context. Similar to me using 32 as a width in several different places. It depends how nitpicky you want to be. In this case I might use something like MAX_PERCENT. It does help with readability as well since when I see that I know the calculations have to do with percentages.

Answer 7

If forced to use a symbol, I might call it N100. That way you can tell what its value is. A long time ago I saw this done for common constants. And negative numbers were prefixed with "M". Why did they do this? Because the computer instruction set couldn't load numbers in line ("immediate"); they had to be fetched from a memory location. And the assembler used symbols to refer to those locations.

Answer 8

I think 100 IS a magic number here.

Percentage is vastly used, but also per mille (1/1000) is often used, and basis point (1/10.000) and percent mille (1/100.000) are used enough to have their own name.

I would change your function to getPerPart(value, part) and getFromPart(value, part), maybe with a default getPerPart(value) and getFromPart(value), which use DEFAULT_PART_VALUE = 100.

Also, you may still want to write a getPercent, in which case the use of hardcoded 100 is fine.

Answer 9

Any number that remains unnamed remains a magic number. It's not related common usage as common usage is relative. The problem with it is "when" or "where" to draw a line... when does a number changes its state to non-magic...

2,71828... may not be magic for mathematicians (Euler)

1760 may not be a magic number for anglo saxons (Yards per mile)

10000000 may not be magic for south inhabitant of south asia (crore)

1 may not be magic in the context of multiplication (neutral element)

The relative approach will lead to a discussion that will evolve a local aggreement. And the result to consider a number to be non-magic, will depend on when and where you start the discussion. Unfortunally this discussion has to be lead for each number separately.

The absolute approach is simple an clear: Every number that is not named is a magic number. Discussion over... for all numbers... Of course this is only a (one) definition. But this definition has inherent properties that will make it possible to evaluate it exactly.

So if you want to discuss, go for the relative approach. You will find the discussions never ending. And if you think it is over another number comes along.

Or you go and find a definition that can be used in boolean expressions that will evaluate to true or false.

I go the second way with following definition: Every unnamed number is magic. Even if you practically ignore it the statement stays the same.