+11  A: 

Yes, they will, please see 10.4.5.1 Static field initialization:

The static field variable initializers of a class correspond to a sequence of assignments that are executed in the textual order in which they appear in the class declaration. If a static constructor (Section 10.11) exists in the class, execution of the static field initializers occurs immediately prior to executing that static constructor. Otherwise, the static field initializers are executed at an implementation-dependent time prior to the first use of a static field of that class.

That being said I think it would be better to do the initialization inside a static type initializer (static constructor).

Andrew Hare
Care to cite evidence?
Marc Gravell
Much better ;-p
Marc Gravell
@Marc - LOL, I posted "yes" so I would be first and then came back with the evidence. Since I can no longer be the FGTW I guess I shouldn't worry about being first anymore :D
Andrew Hare
+2  A: 

Hmm... I'm surprised that compiles (it does, I checked). I'm not aware of any guarantee that would make this safe. Use a static constructor...


Edit: I accept (see better answer above) that it will work; but my idea with code is to keep it as simple and obvious as possible. If it isn't obvious that it will work (and it can't be if you have to ask), then don't write it that way...

In particular, problems with relying on field order:

  • it can break if you move code around (which I often do)
  • it can break if you split the code into partial classes

My advice remains: use a static constructor for this scenario.

Marc Gravell
+1 This advice is sound - just because you _can_ do something doesn't mean you should. I think that a static constructor is the way to go here even though the language does support this type of field initialization.
Andrew Hare
A: 

At first glance, I wouldn't be sure, and I had to try this out to see if it even compiled.

Given that, I would initialize the value in a static constructor.

Jon Seigel