Private mail indicates that my uninitialized-variable comment may not have clearly expressed my point.
My point was that there are tools (lint and the Java compiler come to mind) that statically analyze your program to see if there are any code paths that could end up using the value of a variable before it is set. If you blindly initialize the variable with some nonsense value, you defeat that analysis. That means that instead of your bug showing up as a compile or lint error, it shows up as a runtime error or as corrupted data.
Suppose you have (Java, but the concept applies anywhere):
String s;
while (moonPhase() != FULL) {
s = somefunc();
}
System.out.println(s.length());
That code has a bug in it: if the moon is full the first time, s never gets set. As written, the Java compiler will fail, reporting an error on the println. If, on the other hand, you said "String s = null;", the compiler can't tell that there's anything wrong, but you still end up getting a runtime NullPointerException when it tries to execute s.length(). The compiler is trying to do you a favor, detecting your bug for you, and when you blindly initialize the variable you defeat that and make the bug much harder to detect - now, instead of causing a compile failure, it only fails when the moon is full, and maybe you didn't happen to test then. (One might argue that you should instead initialize s to "". Indeed that will avoid the NPE, but it might well cause some other still more subtle problem.)
Remember that the compiler inspects every single line of your program, while testing only exercises a fraction of the code paths. If you can get the compiler to detect bugs, that's a huge win.