I've read around about const
and static readonly
fields. We have some classes which contains only constant values. 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?
Source: Tips4all
Public static readonly fields are a little unusual; public static properties (with only a get) would be more common (perhaps backed by a private static readonly field).
ReplyDeleteConst values are burned directly into the call-site; this is double edged:
it is useless if the value is fetched at runtime, perhaps from config
if you change the value of a const, you need to rebuild all the clients
but it can be faster, as it avoids a method call...
...which might sometimes have been inlined by the JIT anyway
If the value will never change, then const is fine - Zero etc make reasonable consts ;-p Other than that, static properties are more common.
I would use static readonly if the Consumer is in a different assembly. Having the const and the consumer in two differen assemblies is a nice way to shoot yourself in the foot.
ReplyDeleteOne thing to note is const is restricted to primitive/value types (the exception being strings)
ReplyDeleteSome other things
ReplyDeleteconst int a
must be initialized
initialization must be at compile time
readonly int a
can use default value, without initializing
initialization can be at run time
but please see : http://en.csharp-online.net/const,_static_and_readonly
My preference is to use const whenever I can, which as mentioned above is limited to literal expressions or something that does not require evaluation.
ReplyDeleteIf I hot up against that limitation, then I fallback to static readonly, with one caveat. I would generally use a public static property with a getter and a backing private static readonly field as Marc mentions here.