Friday, June 1, 2012

C#: Static readonly vs const


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

5 comments:

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

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

    ReplyDelete
  2. 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.

    ReplyDelete
  3. One thing to note is const is restricted to primitive/value types (the exception being strings)

    ReplyDelete
  4. Some other things

    const 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

    ReplyDelete
  5. 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.

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

    ReplyDelete