Advantages of using const instead of variables inside methods

Question

Whenever I have local variables in a method, ReSharper suggests to convert them to constants:

// instead of this:
var s = \"some string\";
var flags = Bindin         


        

Answer 1

tl;dr for local variables with literal values, const makes no difference at all.

---

Your distinction of "inside methods" is very important. Let's look at it, then compare it with const fields.

Const local variables

The only benefit of a const local variable is that the value cannot be reassigned.

However const is limited to primitive types (int, double, ...) and string, which limits its applicability.

Digression: There are proposals for the C# compiler to allow a more general concept of 'readonly' locals (here) which would extend this benefit to other scenarios. They will probably not be thought of as const though, and would likely have a different keyword for such declarations (i.e. let or readonly var or something like that).

Consider these two methods:

private static string LocalVarString()
{
    var s = "hello";
    return s;
}

private static string LocalConstString()
{
    const string s = "hello";
    return s;
}

Built in Release mode we see the following (abridged) IL:

.method private hidebysig static string LocalVarString() cil managed 
{
    ldstr        "hello"
    ret          
}

.method private hidebysig static string LocalConstString() cil managed 
{
    ldstr        "hello"
    ret          
}

As you can see, they both produce the exact same IL. Whether the local s is const or not has no impact.

The same is true for primitive types. Here's an example using int:

private static int LocalVarInt()
{
    var i = 1234;
    return i;
}

private static int LocalConstInt()
{
    const int i = 1234;
    return i;
}

And again, the IL:

.method private hidebysig static int32 LocalVarInt() cil managed
{
    ldc.i4       1234
    ret          
}

.method private hidebysig static int32 LocalConstInt() cil managed
{
    ldc.i4       1234
    ret     
}

So again we see no difference. There cannot be a performance or memory difference here. The only difference is that the developer cannot re-assign the symbol.

Const fields

Comparing a const field with a variable field is different. A non-const field must be read at runtime. So you end up with IL like this:

// Load a const field
ldc.i4       1234

// Load a non-const field
ldsfld       int32 MyProject.MyClass::_myInt

It's clear to see how this could result in a performance difference, assuming the JIT cannot inline a constant value itself.

Another important difference here is for public const fields that are shared across assemblies. If one assembly exposes a const field, and another uses it, then the actual value of that field is copied at compile time. This means that if the assembly containing the const field is updated but the using assembly is not re-compiled, then the old (and possibly incorrect) value will be used.

Const expressions

Consider these two declarations:

const int i = 1 + 2;
int i = 1 + 2;

For the const form, the addition must be computed at compile time, meaning the number 3 is kept in the IL.

For the non-const form, the compiler is free to emit the addition operation in the IL, though the JIT would almost certainly apply a basic constant folding optimisation so the generated machine code would be identical.

The C# 7.3 compiler emits the ldc.i4.3 opcode for both of the above expressions.