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 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

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.

Answer 2

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 3

I think that it makes sense to initialize the values if it clarifies the developer's intent.

In C#, there's no overhead as the values are all initialized anyway. In C/C++, uninitialized values will contain garbage/unknown values (whatever was in the memory location), so initialization was more important.

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 agree with you; it may be verbose, but I like to see:

int myBlorgleCount = 0;

Now, I always initial strings though:

string myString = string.Empty;

(I just hate null strings.)

Answer 6

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.

Answer 7

I always initialize fields explicitly in the constructor. For me, it's THE place to do it.

Answer 8

In the case where I cannot immediately set it to something useful

int myValue = SomeMethod();

I will set it to 0. That is more to avoid having to think about what the value would be otherwise. For me, the fact that integers are always set to 0 is not on the tip of my fingers, so when I see

int myValue;

it will take me a second to pull up that fact and remember what it will be set to, disrupting my thought process. For someone who has that knowledge readily available, they will encounter

int myValue = 0;

and wonder why the hell is that person setting it to zero, when the compiler would just do it for them. This thought would interrupt their thought process.

So do which ever makes the most sense for both you and the team you are working in. If the common practice is to set it, then set it, otherwise don't.

Answer 9

http://www.geekherocomic.com/2009/07/27/common-pitfalls-initialize-your-variables/

Answer 10

If a field will often have new values stored into it without regard for what was there previously, and if it should behave as though a zero was stored there initially but there's nothing "special" about zero, then the value should be stored explicitly.

If the field represents a count or total which will never have a non-zero value written to it directly, but will instead always have other amounts added or subtracted, then zero should be considered an "empty" value, and thus need not be explicitly stated.

To use a crude analogy, consider the following two conditions:

1. `if (xposition != 0) ...
2. `if ((flags & WoozleModes.deluxe) != 0) ...

In the former scenario, comparison to the literal zero makes sense because it is checking for a position which is semantically no different from any other. In the second scenario, however, I would suggest that the comparison to the literal zero adds nothing to readability because code isn't really interested in whether the value of the expression (flags & WoozleModes.deluxe) happens to be a number other than zero, but rather whether it's "non-empty".

I don't know of any programming languages that provide separate ways of distinguishing numeric values for "zero" and "empty", other than by not requiring the use of literal zeros when indicating emptiness.

Answer 11

I think a lot of that comes down to past experiences.

In older and unamanged languages, the expectation is that the value is unknown. This expectation is retained by programmers coming from these languages.

Almost all modern or managed languages have defined values for recently created variables, whether that's from class constructors or language features.

For now, I think it's perfectly fine to initialize a value; what was once implicit becomes explicit. In the long run, say, in the next 10 to 20 years, people may start learning that a default value is possible, expected, and known - especially if they stay consistent across languages (eg, empty string for strings, 0 for numerics).

Answer 12

You Should do it, there is no need to, but it is better if you do so, because you never know if the language you are using initialize the values. By doing it yourself, you ensure your values are both initialized and with standard predefined values set. There is nothing wrong on doing it except perhaps a bit of 'time wasted'. I would recommend it strongly. While the commend by John is quite informative, on general use it is better to go the safe path.

Answer 13

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 14

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 15

This is tagged as language-agnostic but most of the answers are regarding C#.

In C and C++, the best practice is to always initialize your values. There are some cases where this will be done for you such as static globals, but there shouldn't be a performance hit of any kind for redundantly initializing these values with most compilers.

Answer 16

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 17

Another thing to remember is, if you are gonna use automatic properties, you have to rely on implicit values, like:

public int Count { get; set; }