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

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

Answer 2

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 3

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 4

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 5

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

Answer 6

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.