18

I've set up some default colors in a C# winforms application like so:

readonly Color ERROR = Color.Red;
readonly Color WARNING = Color.Orange;
readonly Color OK = Color.Green;

As far as I am aware, readonly is essentially a constant for my purposes. If I attempt to define these as constants, the compiler indicates that it must be a compile-time constant, which Color is not.

Am I good leaving these as-is, or is there some way to define these constants that I should be aware of?

(The purpose is simply to have a single location in which to change all of the colors for logging purposes.)

JYelton
  • 35,664
  • 27
  • 132
  • 191

6 Answers6

24

Only literals can be defined as const. The difference is, that const values are hard-bakened into the assemblies that uses it. Should their definition change, then the call sites doesn't notice unless they get recompiled.

In contrast, readonly declares a variable in a way that it cannot be reassigned after outside the constructor (or static constructor in case of a static readonly variable).

So, you have no other way then to use readonly here, since Color is a struct, and no primitive data type or literal.

codymanix
  • 28,510
  • 21
  • 92
  • 151
  • 1
    This is very important, and I would go as far to say that it supports the idea that `readonly static` is the preferred way to `const`. – John Leidegren Mar 21 '11 at 18:24
5

A const field is a compile time constant - you actually need code to run to determine the value of Color.Orange though, internally probably defined as 

public static readonly Color Orange = new Color(...);

Since this cannot be computed at compile time, your only option is readonly which is set at runtime.

Also check out this article.

BrokenGlass
  • 158,293
  • 28
  • 286
  • 335
2

Aside from the technical aspects that others have mentioned (that const values are replaced at compile-time in the places they are used, and are required to be literals rather than static readonly values which are assigned and referenced at runtime) there is a semantic issue to consider.

The reason const values are replaced at compile-time is that const really does mean "constant" - as in a value that will never, ever change such as pi or e. That's why it's safe to replace them at compile-time, because the name represents a forever unchanging value.

The fact that you state...

The purpose is simply to have a single location in which to change all of the colors for logging purposes.

...indicates that these are not semantically constant, and thus should not be defined as const even if it were possible to do so.

Greg Beech
  • 133,383
  • 43
  • 204
  • 250
  • You bring up a good point. In *theory* they won't change, unless management says something like "Hey the red is too hard to read in the log window." – JYelton Mar 21 '11 at 21:50
1

You could at the very least make 'em static. A read-only field is otherwise just that, a field, that can only be assigned to during initilization. It makes no guarantees about the represented value being "read-only".

John Leidegren
  • 59,920
  • 20
  • 131
  • 152
0

This is fine, and you can't do any better (as the compiler tells you).

But do make them static, if they are not already.

Jon
  • 428,835
  • 81
  • 738
  • 806
-1

You can define a static Colors like this:

// tested with C# 5.0
static const Color ERROR = Color.FromArgb(0, 255,0);
static const Color MYPOOL = Color.FromKnownColor(KnownColor.Aqua);
sx2009
  • 15
  • 1