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.
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
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
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
Then, when you need to do a conversion:
rate = discount*PERCENT
discount = rate/PERCENT
This can completely eliminate your short functions (which are, indeed, trivial). You could have additional constants
PPB, etc., and it should be obvious for humans what is happening.
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! 🙂