What are the best practices for Private Member Instantiation/Initialization?

Question

Possible Duplicate:
C# member variable initialization; best practice?

Is there any benefit to this:

public class RemotingEngine
{
    uint m_currentValueId;
    object m_lock;

    public RemotingEngine()
    {
        m_currentValueId = 0;
        m_lock = new object();
    }

vs. this:

public class RemotingEngine
{
    uint m_currentValueId = 0;
    object m_lock = new object();

I have been avoiding the second one just because it feels 'dirty'. It is obviously less typing so that is appealing to me.

exact duplicate of http://stackoverflow.com/questions/298183/c-member-variable-initialization-best-practice — Robert, May 28 '09 at 20:47

score 8 · Accepted Answer · answered May 28 '09 at 20:47

It can make a difference in an inheritance situation. See this link on the object initialization order:
http://www.csharp411.com/c-object-initialization/

Derived static fields
Derived static constructor
Derived instance fields
Base static fields
Base static constructor
Base instance fields
Base instance constructor
Derived instance constructor

So if this is a derived class, the entire base object is initialized between when your derived field is initialized and when your constructor runs.

score 1 · Answer 2 · answered May 28 '09 at 20:44

There's not a whole lot of difference, I'd keep with the first one because it's more readable. Usually variables are defined at the top of the class, and I can go there and check out their default values instead of hunting down a constructor and seeing if it sets it. As far as the compiler is concerned, there is no difference, unless you have multiple constructors.

score 1 · Answer 3 · answered May 28 '09 at 20:45

1

I always use the first one for this reason: It's the responsibility of the constructor to initialize variables. Different constructors may initialize variables differently. So yes, you should feel dirty doing it the second way =).

answered May 28 '09 at 20:45

Artel

93
6

score 1 · Answer 4 · answered May 28 '09 at 20:50

I prefer the second and in some cases it depends on your coding standards. But consider the processing sequence:

target class field initialization -> base class field initialization -> base class constructor -> target class constructor

if the base class or target class has an exception creating the object and the fields are preinitialized it will have a value at finalization and may cause some unexpected problems.

See also this blog by Bill Simser Best Practices and Member Initialization in C#

Andrew Hare · Answer 5 · 2009-05-28T20:49:21.437

0

They are identical as far as the IL is concerned.

The compiler turns this:

class Foo
{
    int bar = 1;
}

into this:

class Foo
{
    int bar;

    public Foo()
    {
        this.bar = 1;
    }
}

Even if you add a constructor yourself like this:

class Foo
{
    int bar = 1;

    public Foo(int bar)
    {
        this.bar = bar;
    }
}

The compiler turns it into this:

class Foo
{
    int bar;

    public Foo(int bar)
    {
        this.bar = 1;
        this.bar = bar;
    }
}

edited May 28 '09 at 20:49

answered May 28 '09 at 20:43

Andrew Hare

344,730
71
640
635

until another constructor is added – Neil N May 28 '09 at 20:45
@Neil N: Please explain more - your statement does not make any sense. – Andrew Hare May 28 '09 at 20:49
In some cases (when you have derived) the IL is definitely NOT the same. – Joel Coehoorn May 28 '09 at 20:54
Do you have a specific example? I fail to see how having a derived type would matter. – Andrew Hare May 28 '09 at 20:55
If an exception occurs during the base class constructor, the derived constructor will not run but the field intializer would. – Joel Coehoorn May 28 '09 at 20:58
But that doesn't change the fact that the compiler moves all field initialization statements into the constructor. The IL *is* the same regardless of whether or not an exception is thrown by the base constructor. – Andrew Hare May 28 '09 at 21:04

score 0 · Answer 6 · answered May 28 '09 at 20:46

For the int, you don't have to do it at all, intrinsic types are initialized to default() - which, for int's is 0.

As for object, it's a matter of taste imo. I prefer the former. If someone is overriding my constructor, I expect them to call base() to construct it in a proper state.

score 0 · Answer 7 · answered May 28 '09 at 20:46

0

you want to avoid instantiation outside of scope of your constructor given that it shows intent and especially if you are overriding constructors you have a bit more flexibility

answered May 28 '09 at 20:46

Brandon Grossutti

1,241
5
16
24

score 0 · Answer 8 · answered May 28 '09 at 20:57

0

I have a different take on this. I think you should abstract to properties and set them in the constructor. Using automatic properties would basically eliminate the question since you aren't able to initialize them (to anything other than the default).

public class RemotingEngine {
    private uint CurrentValueID { get; set; }
    private object Lock { get; set; }

    public RemotingEngine()
    {
        this.CurrentValueID = 0; // not really necessary...
        this.Lock = new object();
    }
}

answered May 28 '09 at 20:57

tvanfosson

524,688
99
697
795

I'm enthusiastic for this with public members, but less so with private members. Many of the arguments (implementation/interface should be separate) in favor of properties are not that relevant when working with private members.. – Brian May 28 '09 at 21:17

What are the best practices for Private Member Instantiation/Initialization?

8 Answers8

Linked