I noticed on a few projects I'm currently working on that the developers are maniacal about initializing variables. That is, either they initialize them when they're declared:
Reporting the slowdowns as a percentage makes them seem much more important than they may be. 
“35% slower” sounds much worse than “It took 0.00003ms per operation rather than 0.0000195ms”
So rather than just focusing on the performance difference, which should really only matter if you notice the difference in your application, think about the other side of the argument. Are there any benefits to initializing your vars other than taking away the nag error?
argh, I hit post too quickly. hehe
My point isn’t that it’s better to initialize your vars, just that the cost-benefits analysis needs to be done for any performance tip. I’m looking over my code and I’m not initializing anything anywhere. Which means I was ahead of the game. I’m going to use that to further my “when you shouldn’t listen to advice from people” rule-of-thumb; which includes “before getting married”, “before the birth of your first child”, and “when programming”.
A .NET compiler should never give an “uninitialized variable” warning except for autos. I do use explicit init values when the variable is some sort of specific numeric value, for example the lower end of a range, even if it’s zero. Makes the code easier to read.
C# 2.0 does indeed strip out variable initializers that merely duplicate the runtime default value; that’s what Gunnerson Wienholt are saying, anyway (“A Programmer’s Introduction to C# 2.0”, Apress).
Initializing in ctors and methods probably can never be optimized away since the compiler or runtime cannot generally know what the variable values are when the method is called. Even if a given chunk of code can be statically analyzed, someone else might derive another type or use reflection from another assembly to call those methods…
Indeed you do get a performance hit for doing so. I think FxCop catches these unnecessary initializations and reports them.
I disagree there. Do please initialize your variables, at least in the constructor. If a C++, C, Java or Cobol coder has a look on your C# code, he may wonder “which value may get this var during run ?”. We need also to get rid with this horrible “string.Empty” or “Null” confusions.
Um, the C++, C, Java or Cobol coder should learn C# if he’s going to maintain C# code. Default null inits are part of the standard, and anyone touching the code can be expected to know this. Or maybe we should all avoid using classes and inheritance since a FORTRAN IV coder might not know such constructs?
Reporting the slowdowns as a percentage makes them seem much more important than they may be.
Of course; I wasn’t trying to artificially inflate the performance rationale. The main reason not to do it is because it’s more unnecessary code that has to be debugged and read by someone. The perf benefits are just a bonus.
In .NET 2.0 the compiler, when set to optimize code, removes redundant variable initialization.
i think it’s a good idea to initialize ALL variables, even if u know that there is no need in doing that
the main reason of doing so is my paranoidal programmer’s aspiration 4 maximum safety of written code
initializin’ variables is after all a good style of coding, i think: it works anywhere always
If you’re worried about performance you won’t be using c# so initialise your variables and if your code is too slow get a bigger box or use C++!
good
private int n = 0;
Wouldn’t readability count more than some of performance lost?
I do not initialize objects to null
but I tend to initialize integer(double, float, etc, but not structs) values.
To me,
private int _ProcessCounter = 0; looks a lot more readable than having to think what default value of _ProcessCounter is.
I rather sacrifice some performance to gain more readability as long as performance becomes a major problem. I can always refactor and optimize my code later on more easily since the code is more readable.
A lot of us have had variable initialization drilled into us, so it can be a hard habit to break. I have gotten better though.
What really sucks though is that a local variable must be initialized(at least in C#). For example, this snippet will cause a compiler error:
MyObject obj;
if(condition)
obj = new MyObject();
return obj;
So, in my mind, we have two conflicting messages being conveyed. I know the difference between the two cases, but I’m not sure I understand why the object gets implicitly set to null in one case but not in the other. In the example I posted, null might be a perfectly acceptable return value, but I would have to append an " = null; " on it to keep the compiler from complaining.
The original post discussed initialization of member variables in a class, so my apologies if I go too far off topic by discussing local variables defined within the scope of a method.
Before getting into that, though, my 2 cents on the member variable initialization is this: don’t initialize variables unnecessarily; let your code do the talking. If someone needs to understand what’s going on, they can read the code for themselves. Presumably they should have enough grasp of the language to figure it out. If something is so obscure that you feel the need to clarify what’s going on by adding a line to your constructor such as “myObject = null;” or “counter = 0”, then why not add some comments instead? My initial benchmarking tests show that comments added to a constructor do not add significant performance penalty to the execution time.
One thing that kind of annoys me, however, is seeing code such as the following:
// unnecessary initialization of data variable
MyObject data = new MyObject();
// data variable is immediately assigned another value
data = CreateMyObject();
Generally I don’t make a fuss about this and if it’s early enough in the development cycle that I feel that this can be safely changed then I will remove the unnecessary constructor call. However, I see this quite frequently, and to me it seems like an indicator that the author of the code doesn’t quite fully have a grasp of what their method is doing. That last statement might seem like a bit of a stretch for me to make such a claim. Let me illustrate with a somewhat similar example:
Let’s say I am writing a function that writes out to the console the min and max values contained in an array of integers. Ordinarily I might make it a function with output parameters or something, but I am writing to the console for the sake of simplicity. Within my function I would define a min variable and a max variable, neither of which are initialized immediately:
public static void ReportMinAndMaxValues(int[] values)
{
int minValue;
int maxValue;
if (values != null && values.Length > 0)
{
minValue = maxValue = values[0];
for (int i = 1; i < values.Length; i++)
{
if (values[i] < minValue)
minValue = values[i];
if (values[i] > maxValue)
maxValue = values[i];
}
Console.WriteLine("Min Value: {0}, Max Value: {1}", minValue, maxValue);
}
else
{
Console.WriteLine("The list of values is empty, therefore there is no min value and no max value.");
}
// this line cannot compile because minValue and maxValue have not been assigned
// "It's a good thing."
//Console.WriteLine("Min Value: {0}, Max Value: {1}", minValue, maxValue);
}
I, for one, am quite glad that the C# compiler does not allow me to use minValue or maxValue until they have definitely been initialized. It would be improper for me to do so, but I feel that many people don’t quite grasp that. Instead they circumvent this compiler check by initializing a variable prematurely, such as in these two examples:
public static void ReportMinAndMaxValues_PoorExample1(int[] values)
{
int minValue;
int maxValue;
// no check for null or empty array, so an exception will be thrown
minValue = maxValue = values[0];
for (int i = 0; i < values.Length; i++)
{
if (values[i] < minValue)
minValue = values[i];
if (values[i] > maxValue)
maxValue = values[i];
}
Console.WriteLine("Min Value: {0}, Max Value: {1}", minValue, maxValue);
}
public static void ReportMinAndMaxValues_PoorExample2(int[] values)
{
int minValue = int.MaxValue;
int maxValue = int.MinValue;
if (values != null && values.Length > 0)
{
minValue = maxValue = values[0];
for (int i = 1; i < values.Length; i++)
{
if (values[i] < minValue)
minValue = values[i];
if (values[i] > maxValue)
maxValue = values[i];
}
}
// If the array is null or empty, this will incorrectly report int.MaxValue and int.MinValue as the min and max values.
Console.WriteLine("Min Value: {0}, Max Value: {1}", minValue, maxValue);
}
The problems illustrated in this example are centered around whether the values parameter is null or empty, but in general problems caused by premature variable initialization will be specific to the function in which they are used. However, I would imagine that mostly those problems would be a mis-handling of edge cases.
Isn’t it true that not initializing variables is a security vulnerability?
Not in a managed (safe) language. In an unsafe language like C or C++, absolutely!