Should I always/ever/never initialize object field

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 strikes me that I'm not sure that it's always a good idea to have it do this. My thinking is that if I see a declaration like this:

int myBlorgleCount = 0;

I have a pretty good idea that the programmer expects the count to start at zero, and is okay with that, at least for the immediate future. On the other hand, if I just see:

int myBlorgleCount;

I have no real immediate idea if 0 is a legal or reasonable value. And if the programmer just starts reading and modifying it, I don't know whether the programmer meant to start using it before they set a value to it, or if they were expecting it to be zero, etc.

On the other hand, some fairly smart people, and the Visual Studio code cleanup utility, tell me to remove these redundant declarations. What is the general consensus on this? (Is there a consensus?)

I marked this as language agnostic, but if there is an odd case out there where it's specifically a good idea to go against the grain for a particular language, that's probably worth pointing out.

EDIT: While I did put that this question was language agnostic, it obviously doesn't apply to languages like C, where no value initialization is done.

EDIT: I appreciate John's answer, but it is exactly what I'm not looking for. I understand that .NET (or Java or whatever) will do the job and initialize the values consistently and correctly. What I'm saying is that if I see code that is modifying a value that hasn't been previously explicitly set in code, I, as a code maintainer, don't know if the original coder meant it to be the default value, or just forgot to set the value, or was expecting it to be set somewhere else, etc.

Answer 1

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 2

I wouldn't initialise them. If you keep the declaration as close as possible to the first use, then there shouldn't be any confusion.

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

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 6

Think long term maintenance.

• Keep the code as explicit as possible.
• Don't rely on language specific ways to initialize if you don't have to. Maybe a newer version of the language will work differently?
• Future programmers will thank you.
• Management will thank you.
• Why obfuscate things even the slightest?

Update: Future maintainers may come from a different background. It really isn't about what is "right" it is more what will be easiest in the long run.