'Static readonly' vs. 'const'

I've read around about `const` and `static readonly` fields. We have some classes which contain only constant values. They are used for various things around in our system. So I am wondering if my observation is correct:

Should these kind of constant values always be `static readonly` for everything that is public? And only use `const` for `internal`/`protected`/`private` values?

What do you recommend? Should I maybe even not use `static readonly` fields, but rather use properties maybe?

const:

1. value should be given upon declaration
2. compile time constant

readonly:

1. value can be given upon declaration or during runtime using constructors.The value may vary depend upon the constructor used.
2. run time constant

A static readonly field is advantageous when exposing to
other assemblies a value that might change in a later version.

For instance, suppose assembly `X` exposes a constant as follows:

public const decimal ProgramVersion = 2.3;

If assembly `Y` references `X` and uses this constant, the value 2.3
will be baked into assembly `Y` when compiled. This means that
if `X` is later recompiled with the constant set to 2.4, `Y` will still
use the old value of 2.3 until `Y` is recompiled. A static
readonly field avoids this problem.

Another way of looking at this is that any value that might
change in the future is not constant by definition, and so should
not be represented as one.

> **Const:** Const is nothing but "constant", a variable of which the value is constant but at compile time. And it's mandatory to assign a value to it. By default a const is static and we cannot change the value of a const variable throughout the entire program.
>
> **Static ReadOnly:** A Static Readonly type variable's value can be assigned at runtime or assigned at compile time and changed at runtime. But this variable's value can only be changed in the static constructor. And cannot be changed further. It can change only once at runtime

Reference: [c-sharpcorner][1]


[1]:

[To see links please register here]

I would use `static readonly` if the *Consumer* is in a different assembly. Having the `const` and the *Consumer* in two different assemblies is a nice way to [shoot yourself in the foot][1].


[1]:

[To see links please register here]

This is just a supplement to the other answers. I will not repeat them (now four years later).

There are situations where a `const` and a non-const have different semantics. For example:

const int y = 42;

static void Main()
{
short x = 42;
Console.WriteLine(x.Equals(y));
}

prints out `True`, whereas:

static readonly int y = 42;

static void Main()
{
short x = 42;
Console.WriteLine(x.Equals(y));
}

writes `False`.

The reason is that the method [`x.Equals`](

[To see links please register here]

) has two overloads, one that takes in a `short` (`System.Int16`) and one that takes an `object` (`System.Object`). Now the question is whether one or both apply with my `y` argument.

When `y` is a compile-time constant (literal), the `const` case, it becomes important that there does exist an implicit conversion _from_ `int` _to_ `short` provided that the `int` is a constant, and provided that the C# compiler verifies that its value is within the range of a `short` (which `42` is). See [Implicit constant expression conversions](

[To see links please register here]

) in the C# Language Specification. So both overloads have to be considered. The overload `Equals(short)` is preferred (any `short` is an `object`, but not all `object` are `short`). So `y` is converted to `short`, and that overload is used. Then `Equals` compares two `short` of identical value, and that gives `true`.

When `y` is not a constant, no _implicit_ conversion from `int` to `short` exists. That's because in general an `int` may be too huge to fit into a `short`. (An _explicit_ conversion does exist, but I didn't say `Equals((short)y)`, so that's not relevant.) We see that only one overload applies, the `Equals(object)` one. So `y` is boxed to `object`. Then `Equals` is going to compare a `System.Int16` to a `System.Int32`, and since the run-time types do not even agree, that will yield `false`.

We conclude that in some (rare) cases, changing a `const` type member to a `static readonly` field (or the other way, when that is possible) can change the behavior of the program.