[ACCEPTED]-When, if ever, should we use const?-readonly

Accepted answer
Score: 38

I believe the only time "const" is appropriate 15 is when there is a spec that you're coding 14 against that is more durable than the program 13 you're writing. For instance, if you're 12 implementing the HTTP protocol, having a 11 const member for "GET" is appropriate because 10 that will never change, and clients can 9 certainly hard-code that into their compiled 8 apps without worrying that you'll need to 7 change the value later.

If there's any chance 6 at all you need to change the value in future 5 versions, don't use const.

Oh! And never 4 assume const is faster than a readonly field 3 unless you've measured it. There are JIT 2 optimizations that may make it so it's actually 1 exactly the same.

Score: 16

Const vs readonly:

A quick synopsis on the differences between 6 'const' and 'readonly' in C#: 'const':

  • Can't be static.
  • Value is evaluated at compile time.
  • Initiailized at declaration only.


  • Can be either instance-level or static.
  • Value is evaluated at run time.
  • Can be initialized in declaration or by code in the constructor.

Correction: the 5 above states const can't be static. That 4 is a misnomer. They can't have the static 3 keyword applied because they are already 2 static.

So you use const for static items 1 that you want evaluated at compile-time.

Score: 5

You can use a const value as a case in a 1 switch statement, fwiw.

Score: 4

I typically only use const for things that 8 I know will never ever change such as the speed of 7 light in a vacuum.

I prefer readonly for 6 things that could potentially change. This way I only 5 need to recompile one dll if a change happens. An 4 exception to this rule of thumb is if the 3 variable is private/protected/friendly to 2 its own assembly. In those cases it is safe 1 to use const.

Score: 3

readonly is useful when the initialization 12 is not straight forward.
const can be used 11 when you are sure of the value before it 10 is compiled.

In a way, readonly is a runtime 9 const & const is a compile time constant 8 value.

EDIT: If you look at some code using 7 www.koders.com, you will find that there 6 is a use of readonly where const could have 5 been used. I think, the reason behind that 4 could be it is modifiable in the constructor 3 (if need be). In case of const (especially 2 public), you have a chance of breaking the 1 client code dependent on your code.

Score: 2

const cannot be used for classes or structures 11 (except for string constants and null, as 10 Mr. Skeet pointed out), only for value types 9 and are accessed as static fields. A const's 8 value is set at compile time and must be 7 set when it is declared.

readonly can be 6 used for anything except enumerations and 5 can be either a static or instance field. A 4 readonly's value is set at runtime and can 3 be set differently depending on which constructor 2 is called.

Here's a good page for an overview of the const, readonly 1 and static keywords.

Score: 1

You should prefer modifier that are tested 7 at compile time over modifier that are tested 6 during runtime (in this context const over 5 readonly). And you should always use the 4 modifiers that support the semantic you 3 need. If something isn't meant to be modified 2 - protect it or someone will write something 1 to it (by accident or by ignorance).

Score: 0

You should use const whenever you can set 2 the value in the declaration and don't have 1 to wait for the constructor.

Score: 0

A good use of const is for keys of key/value 6 pairs. For example, if you are still using 5 AppSetting (instead of ApplicationSettings), it 4 doesn't really make sense to load the name of 3 the key to a configuration setting. If 2 it is used in several place, stick the Key 1 in a const.

Score: 0

Use const when your fields are of simple type (number, Boolean 6 or string) and their values will never be 5 changed. If you change their values, the 4 project should be recompiled.

Use readonly fields 3 when they are initialized from another source (file, database or other codes, ..etc.) but 2 then they will not be changed.

Use static readonly fields 1 when you want to make them shared by all instances.

Score: 0

A particular use I've found for consts is 4 reusable "magic" strings used in attributes, since 3 they can only be consts, you cannot use 2 static readonlys.

My particular use case 1 was the ASP.NET authorisation attribute

[Authorize(Roles = Roles.FirstParty)]

More Related questions