Constant Declarations vs Hard-Coded Literals in C#

One of the most recurring debates I've had in every development team I've been part of is whether to favor constant declaration over hard-coded literals or not.

As always, there is not a straight answer because it depends on several factors such as:
  1. Is the value used more than once in your code?
  2. Is the value meaningful outside the context is being used?
  3. What kind of type are we talking about?
  4. What makes the code more readable?
But first let's start by analyzing what constants and literals really are. Literals are constants, in fact they are synonyms. They are simply values that cannot change during code execution, so what we're discussing here is whether we should declare constants like const <data_type> <constant_name> = value; as in:

private const string Greeting = "Welcome to Diego Driven Design"
or simply not to declare them beforehand and use the literal when needed (the hard-coded way) as in:

SayGreeting("Welcome to Diego Driven Design");
Now let's have a look at how a C# code compiles to IL (Common Intermediate Language) when using the first approach and when using the second. To do the comparison we can use ReSharper, PEVerify.exe or any other tool available to browse compiled code in .Net

The following class that uses constant declaration:
generates the following IL:
And the following class that hard-codes the literals:
generates the following IL:
As you can see, the compiled code is identical regarding the instruction to print on console the greeting. In both cases the compiler does exactly the same with the code, it declares a constant internally and later it uses it, so there are no benefits of one way over the other in terms of performance. That leaves the debate to be decided upon other factors such as reducing error prone code and improve readability. After all, let's not forget we write code primarily for other developers and ourselves to read it later on.

What's best for reducing error prone code?

Let's be clear here. If the same value is used more than once in our code, this value should be extracted into a constant declaration. There is no question about that because:

  • If you refactor your code and change the value you don't need to go one by one finding all the hard-coded literals changing them
  • It avoids making a mistake (e.g: a typo) in any of the values, you just have to focus in not making mistakes when declaring the only constant you will be using
If the same value is used across different classes and files, you can place the constant declaration in a class that has the only responsibility of keeping all the constants for a specific context within your application. If the value is used in different methods within the same class, you should declare the constant as a private member of the class (pascal case naming convention), and if the value is used multiple times within the same method you should declare the constant inside this method as a local constant (camel case naming convention). Always declare the constant inside the context where is going to be used.

What's best for improving readability?

Here's where the debate is really open. Again, there's no question that if a value is used multiple times, there should be a single constant declaration to reuse this value. But what if the value is used once and only once? 

The answer here is: it depends on each case.
Let's imagine the value is an Integer literal such as the number of working days per week for a worker, which is 5. If we use the hard-coded literal in the following way:

then somebody who is reading our code may wonder what's the magic number about. However if we had used the value in the following way:

any potential reader would immediately know what that value means and understands the code better.

But let's imagine now that our value is a string such as a greeting sentence that we want to use only once in a specific context. If we do something like this:
Wouldn't that be more meaningful than extracting the greeting into a constant that, honestly, we wouldn't be able to find a good name for such as:
Always wonder what's more meaningful for somebody who is going to read our code. If declaring a constant can help to understand better the magic literal, go ahead. But if the name you would give to a constant is something that does not make things more readable, just use the hard-coded literal because that's probably way more meaningful. Of course, as long as this literal is used just once in a specific context.