Should Local Variable Initialisation Be Mandatory?

Question

The maintenance problems that uninitialised locals cause (particularly pointers) will be obvious to anyone who has done a bit of c/c++ maintenance or enhancement, but I still se

Answer 1

As a simple example, can you determine what this will be initialised to (C/C++)?

bool myVar;

We had an issue in a product that would sometimes draw an image on screen and sometimes not, usually depending on who's machine it was built with. It turned out that on my machine it was being initialised to false, and on a colleagues machine it was being initialised to true.

Answer 2

Sometimes a variable is used to "collect" the result of a longer block of nested ifs/elses... In those cases I sometimes keep the variable uninitialized, because it should be initialized later by one of the conditional branches.

The trick is: if I leave it uninitialized at first and then there's a bug in the long if/else block so the variable is never assigned, I can see that bug in Valgrind :-) which of course requires to frequently run the code (ideally the regular tests) through Valgrind.

Answer 3

This is a great example of Premature optimization is the root of all evil

The full quote is:

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.

This came from Donald Knuth. who are you going to believe...your colleagues or Knuth?
I know where my money is...

To get back to the original question: "Should we MANDATE initialization?"
I would phrase it as so:

Variables should be initialize, except in situation where it can be demonstrated there is a significant performance gain to be realized by not initializing. Come armed with hard numbers...

Answer 4

Always initialize local variables to zero at least. As you saw, there's no real performance it.

int i = 0;
struct myStruct m = {0};

You're basically adding 1 or 2 assembly instructions, if that. In fact, many C runtimes will do this for you on a "Release" build and you won't be changing a thing.

But you should initalize it because you will now have that guarantee.

One reason not to initialize has to do with debugging. Some runtimes, eg. MS CRT, will initialize memory with predetermined and documented patterns that you can identify. So when you're pouring through memory, you can see that the memory is indeed uninitialized and that hasn't been used and reset. That can be helpful in debugging. But that's during debugging.

Answer 5

In C/C++ I totally agree with you.

In Perl when I create a variable it is automatically put to a default value.

my ($val1, $val2, $val3, $val4);
print $val1, "\n";
print $val1 + 1, "\n";
print $val2 + 2, "\n";
print $val3 = $val3 . 'Hello, SO!', "\n";
print ++$val4 +4, "\n";

They are all set to undef initially. Undef is a false value, and a place holder. Due to the dynamic typing if I add a number to it, it assumes that my variable is a number and replaces undef with the eqivilent false value 0. If i do string operations a false version of a string is an empty string, and that gets automatically substituted.

[jeremy@localhost Code]$ ./undef.pl

1
2
Hello, SO!
5

So for Perl at least declare early and don't worry. Especially as most programs have many variables. You use less lines and it looks cleaner without explicit initializing.

 my($x, $y, $z);

:-)

 my $x = 0;
 my $y = 0;
 my $z = 0;