Is it bad practice to initialise fields outside of an explicit constructor

Question

Possible Duplicate:
Initialize class fields in constructor or at declaration?

We are arguing about coding practices. The examples here are a little too simple, but the real deal has several constructors. In order to initialise the simple values (eg dates to their min value) I have moved the code out of the constructors and into the field definitions.

public class ConstructorExample
{
    string _string = "John";
}

public class ConstructorExample2
{
    string _string;

    public ConstructorExample2()
    {
        _string = "John";
    }
}

How should it be done by the book? I tend to be very case by case and so am maybe a little lax about this kind of thing. However i feel that occams razor tells me to move the initialisation out of multiple constructors. Of course, I could always move this shared initialisation into a private method.

The question is essentially ... is initialising fields where they are defined as opposed to the constructor bad in any way?

The argument I am facing is one of error handling, but i do not feel it is relevant as there are no possible exceptions that won't be picked up at compile time.

Answer 1

Note that all such field declaration-level initialization will be performed once for each constructor-chain, even if the constructor by itself sets the field to something else.

If you chain constructors together, the fields will be initialized in the common, first, constructor that is called.

Look at this example:

using System;

namespace ClassLibrary3
{
    public class Class1
    {
        private string _Name = "Lasse";

        public Class1()
        {
        }

        public Class1(int i)
            : this()
        {
        }

        public Class1(bool b)
        {
            _Name = "Test";
        }
    }
}

This code compiles as this:

using System;

namespace ClassLibrary3
{
    public class Class1
    {
        private string _Name;

        public Class1()
        {
            _Name = "Lasse"
        }

        public Class1(int i)
            : this()
        {
            // not here, as this() takes care of it
        }

        public Class1(bool b)
        {
            _Name = "Lasse"
            _Name = "Test";
        }
    }
}

Answer 2

It's not necessarily bad to initialize values outside of the constructor, and the problem you have here:

 string _string;

    public ConstructorExample2()
    {
        _string = "John";
    }

Is that if you have multiple constructors you have to remember to either
1. Reinitialize _string in every constructor
2. Separate the logic out into a common method and call that method in every constructor
3. Call the constructor with the logic in it, from the other constructors. (Chain the constructors)
Now this isn't necessarily a problem, but you have to remember to do it. By initializing it outside of the constructor, it's done for you. It's one less thing you need to remember to do.

Answer 3

Microsoft FxCop by default recommends field initializers over using the constructor. This question is also a duplicate of this one and should provide some insight.

With static classes, you'll have to note some subtleties as addressed at this question.

Answer 4

In the above example the assignment of "John" to _string has no logical reliance on any variables and therefore it should be outside of the constructor in the field initializer.

So long as it is not possible to initialize the object in an non-usable state then it doesn't matter.

When the code is compiled both approaches will be the same anyway.

Answer 5

Not sure about C#, but in Java source code they seem to prefer the constructor, example:

public class String{
    char[] value;
    int offset;
    ...
    public String(){
        value = new char[0];
        offset = 0;
        ...
    }
} 

Answer 6

I think for simple initializations like that it's fine to do it in the declaration. However, I don't understand the error handling argument. Even if there is an exception in the initialization, I think you will find that your normal error handling mechanism will work the same. It will still throw an exception when you call the constructor.

Answer 7

I tend to initialize things in the get accessor, where they are first used. If null then initialize and all that.

Answer 8

I prefer to initialize simple fields like that outside of the constructor.

It shouldn't cause any issues since compilation actually moves those initializations into the constructor at compile-time anyway.

Answer 9

If the initialization of the variable will be the same, no matter what arguments are passed to the constructor, then it doesn't make sense to clutter the constructor method with the unnecessary initialization code. In this case, I initialize in-place.

Answer 10

Inisialing the fields in the constructor is better. This way if/when a different constructor is added you know that all the fields are starting with null/default values and you can initialise them appropriately.