Most of my work is on code that has “initialize all local variables at declaration time” as part of the coding standard. I’ve never been a big fan, but I’m very reluctant to get into coding-standard arguments (probably as the result of having had to enforce them for so long) so I just let it go. The other day, Rusty Russell offered up a better reason to avoid this particular standard. The crux of the matter is that there’s a difference between a value being initialized vs. it being initialized correctly, and the difference is too subtle to define a usable standard. Sometimes there is a reasonable default value, and you want to initialize to that value instead of setting it in ten different places. Other times every value has a distinct important meaning, and code depends on a variable having one of those instead of a bland default. Does NULL mean “unassigned” or “no such entry” or “allocate for me” or something else? The worst part of all this is that required initializers prevent compilers and static-analysis tools from finding real uninitalized-variable errors for you. As far as they’re concerned it was initialized; they don’t know that the initial value, if left alone, will cause other parts of your program to blow up. If you need a real value, what you really want to do is leave the variable uninitialized at declaration time, and let compilers etc. do what they’re good at to find any cases where it’s used without being set to a real value first. If your coding standard precludes this, your coding standard is hurting code quality.

Rusty suggests that new languages should be designed with a built-in concept of undefined variables. At the very least, each type should have a value that can not be set, and that only the interpreter/compiler can check. This last part is important, because otherwise people will use it to mean NULL, with all of the previously-mentioned ambiguity that entails. The “uninitialized” value for each type should mean only that – never “ignored” or “doesn’t matter” or anything else. A slightly better approach is to make “uninitialized” only one of many variable annotations that are possible, as in cqual. Maybe some of that functionality will even be baked into gcc or LLVM (small pieces already are), providing the same functionality in current languages. Until then, the best option is to educate people about why it can sometimes be good to leave variables uninitialized until you have a real value for them.