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

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.

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.

'readonly':

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

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

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.

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.

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.

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

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

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.

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.

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)]