Should I always/ever/never initialize object fields to default values?

Question

Code styling question here.

I looked at this question which asks if the .NET CLR will really always initialize field values. (The answer is yes.) But it

Answer 1

I usually do it for strings and in some cases collections where I don't want nulls floating around. The general consensus where I work is "Not to do it explicitly for value types."

Answer 2

I wouldn't do it. C# initializes an int to zero anyways, so the two lines are functionally equivalent. One is just longer and redundant, although more descriptive to a programmer who doesn't know C#.

Answer 3

You are always safe in assuming the platform works the way the platform works. The .NET platform initializes all fields to default values. If you see a field that is not initialized by the code, it means the field is initialized by the CLR, not that it is uninitialized.

This concern is valid for platforms which do not guarantee initialization, but not here. In .NET, is more often indicates ignorance from the developer, thinking initialization is necessary.

---

Another unnecessary hangover from the past is the following:

string foo = null;
foo = MethodCall();

I've seen that from people who should know better.

Answer 4

I think it should be done if it really helps to make the code more understandable.

But I think this is a general problem with all language features. My opinion on that is: If it is an official feature of the language, you can use it. (Of course there are some anti-features which should be used with caution or avoided at all, like a missing option explicit in Visual Basic or diamond inheritance in C++)

There was I time when I was very paranoid and added all kinds of unnecessary initializations, explicit casts, über-paranoid try-finally blocks, ... I once even thought about ignoring auto-boxing and replacing all occurrences with explicit type conversions, just "to be on the safe side".

The problem is: There is no end. You can avoid almost all language features, because you do not want to trust them.

Remember: It's only magic until you understand it :)

Answer 5

In my experience I've found that explicitly initializing local variables (in .NET) adds more clutter than clarity.

Class-wide variables, on the other hand should always be initialized. In the past we defined system-wide custom "null" values for common variable types. This way we could always know what was uninitialized by error and what was initialized on purpose.