Usage of magic strings/numbers

Question

This is somewhat controversial topic, and I guess there is as many opinions as there are programmers. But for the sake of it, I want to know what are the common practices in business (or in your work places).

In my work place we have a strict coding guidelines. One section of that is dedicated to magic strings/numbers. It states (for C#):

Do not use literal values, either numeric or strings, in your code other than to define symbolic constants. Use the following pattern to define constants:

public class Whatever  
{  
   public static readonly Color PapayaWhip = new Color(0xFFEFD5);  
   public const int MaxNumberOfWheels = 18;  
}

There are exceptions: the values 0, 1 and null can nearly always be used safely. Very often the values 2 and -1 are OK as well. Strings intended for logging or tracing are exempt from this rule. Literals are allowed when their meaning is clear from the context, and not subject to future changes.

mean = (a + b) / 2; // okay  
WaitMilliseconds(waitTimeInSeconds * 1000); // clear enough

An ideal situation would be some official research paper showing effects on readability/maintainability of the code when:

• Magic numbers/strings are all over the place
• Magic strings/numbers are replaced by constant declarations reasonably (or in different degrees of coverage) - and please don't shout at me for using "reasonably", I know everyone has different idea what "reasonably" is
• Magic strings/numbers arereplaced in excess and in places where they wouldn't have to be (see my example below)

I would like to do this to have some scientificaly-based arguments when arguing with one of my collegues, who is going to the point of declaring constants like:

private const char SemiColon = ';';
private const char Space = ' ';
private const int NumberTen = 10;

Another example would be (and this one is in JavaScript):

var someNumericDisplay = new NumericDisplay("#Div_ID_Here");

Do you stick DOM IDs on top of your javascript file if that ID is used only in 1 place?

I have read the following topics:
StackExchange
StackOverflow
Bytes IT Community
There is many more articles, and after reading these some patterns emerge.

So my question is should be using magic strings and numbers in our code? I am specifically looking for expert answers that are backed by references if possible.

Answer 1

... when arguing with one of my collegues, who is going to the point of declaring constants like:

private const char SemiColon = ';';
private const char Space = ' ';
private const int NumberTen = 10;

The argument you need to be making with your colleague isn't about naming a literal space as Space but his poor choice of name for his constants.

Let's say your code's job is to parse a stream of records which contain fields separated by semicolons (a;b;c) and are themselves separated by spaces (a;b;c d;e;f). If whoever wrote your spec calls you up a month from now and says, "we were mistaken, the fields in the records are separated by pipe symbols (a|b|c d|e|f)," what do you do?

Under the value-as-name scheme your colleague prefers, you'd have to change the value of the literal (SemiColon = '|') and live with code that continues to use SemiColon for something that isn't really a semicolon anymore. That will lead to negative comments in code reviews. To abate that, you could change the name of the literal to PipeSymbol and go through and change every occurrence of SemiColon to PipeSymbol. At that rate you might as well have just used a literal semicolon (';') in the first place, because you'll have to evaluate each use of it individually and you'll be making the same number of changes.

Identifiers for constants need to be descriptive of what the value does, not what the value is, and that's where your colleague has made a left turn into the weeds. In the field-splitting application described above, the semicolon's purpose is a field separator, and the constants should be named accordingly:

private const char FieldSeparator = ';';    // Will become '|' a month from now
private const char RecordSeparator = ' ';
private const int MaxFieldsPerRecord = 10;

This way, when the field separator changes, you change exactly one line of code, the declaration of the constant. Someone looking at the change will see just that one line and will immediately understand that the field separator changed from a semicolon to a pipe symbol. The remainder of the code, which didn't need to change because it was using a constant, remains the same, and the reader doesn't have to dig through it to see what else was done to it.

Answer 2

Defining semicolon as a constant is redundant, because semicolon is already constant by itself. It is not going to ever change.

It's not like one day somebody will announce "change of terminology, + is the new semicolon now", and your colleague will happily rush just to update the constant (they laughed at me - look at them now).

There's also a matter of consistency. I guarantee that his NumberTen constant will NOT be used by everyone (most coders are not out of their mind), so it won't serve whatever purpose it was expected to anyway. When the apocalypse comes and "ten" gets globally rescaled to 9, updating the constant will NOT do the trick, because it will still leave you with a heap of literal 10s in your code, so now the system becomes totally unpredictable even within the scope of a revolutionary assumption that "ten" means "9".

Storing all settings as consts is something I'd have second thoughts about, too. One should not do this lightly.

What examples of this type of use have we gathered so far? Line terminator... max retry count... max number of wheels... are we positive these will never change?

The cost is that changing default settings requires recompiling an application, and in some cases, even its dependencies (as numeric const values may get hard-coded during compilation).

There's also the testing and mocking aspect. You defined the connection string as a const, but now oops you can't mock database access (establish a fake connection) in your unit test.

Answer 3

private const char SemiColon = ';';
private const char Space = ' ';
private const int NumberTen = 10;

So your colleague is aiming for a Daily WTF entry. Those definitions are silly and redundant. However, as has been pointed out by others, the following definitions would not be silly or redundant:

private const char StatementTerminator = ';';
private const char Delimiter = ' ';
private const int  BalanceInquiryCode = 10;

"Magic" numbers and strings are constants that have meaning beyond their immediate, literal value. If the constant 10 has meaning beyond "ten things" (say as a code for a specific operation or error condition), that's when it becomes "magic" and should be replaced by a symbolic constant that describes that abstract meaning.

Beyond clearly describing intent, symbolic constants also save you some headaches when you misspell a literal. A simple transposition from "CVS" to "CSV" in one line of code got all the way through unit testing and QA and made it into production, where it caused a particular operation to fail. Yes, obviously the unit and QA tests were incomplete and that's it's own problem, but using a symbolic constant would have avoided that bit of heartburn altogether.

Answer 4

There shouldn't be anything controversial about it. The point is not about wether to use magic numbers or not, the point is to have readable code.
Consider the difference between: if(request.StatusCode == 1) and if(request.HasSucceeded). In this case, I would argue the latter is far more readable, but that doesn't mean you can't ever have code like int MaxNumberOfWheels = 18.

P.S.: This is why I absolutely hate coding guidelines. Developers should be mature enough to be capable of making judgement calls like this; they shouldn't leave it to a piece of text formed by god knows who.