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.


  ... 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.
