CleanCode::Code::Variables (VR4)

The assumption referred to here is that of implicit variable initialization. Certain languages in certain cases document that they will auto-initialize your variables. That doesn't make it a good idea. I will stipulate, however, that it is acceptable to do on rare occasions.

Perl initialization

my $x; # declaration
print "x = $x\n";

Results in:

Use of uninitialized value

Perl does not auto-initialize variables. As shown, you can declare a variable $x, but it is undefined if you attempt to use it without initializing it. Makes a lot of sense, no? Actually, there is one case where Perl violates this precept, though you could call it a benefit of the push command rather than a deficit of the no-auto-initialization guideline. That is, you may push a value onto an undefined list variable, as in push @arr, "xyz". The push command is smart enough to start a new list with the element provided if the list variable is not defined.

An undefined value in Perl is a logical false, just as does a numeric 0 or an empty string. So while you could test an undefined value, you'll get warnings about it when you have warning notification activated. Plus it is sloppy. Did you really expect that that variable might be undefined or does your code just happen to work in that situation? Use Perl's defined operator which cleanly identifies whether a value is defined or not, as in if (defined($x)) { .... Perl also offers the neat feature that you can make variables again be undefined by simply assigning the undef value, Perl's constant value indicating undefined.

JavaScript: Defining "defined"

function defined(x) {
	return (x != undefined);
}

In JavaScript, variables are also not initialized automatically. All variables start with the value undefined until initialized explicitly by you. JavaScript has two different behaviors for referencing undefined values, however, depending on how you created them. You may reference undefined variables, but not undeclared variables (see VR2). JavaScript will give a runtime error for the latter case. But if you do declare your variables with the var keyword, then when you reference one, you'll get the undefined value (or NaN in numeric contexts). Unlike Perl, JavaScript allows you to reference such undefined values without complaint. And, JavaScript does not offer the defined operator like Perl, so either you can test against the undefined value, as in if (x == undefined) { ... or you can create the defined operator as a function, as shown.

JavaScript further confuses the issue by having null as distinct from undefined, though they are semantically equal (but not identical). In JavaScript, though, it is more typical to compare against null rather than undefined, as in if (window != null) { .... Got that? See the excellent JavaScript reference card at visibone for no further discussion. That is, to see nothing. I mean, for a discussion of nothingness, wherein they claim, "JavaScript has more kinds of nothing than any other language."

Java: Fields vs. locals

public class TestClass {
    public int field;

    public static void main(String[] args) {
        TestClass t = new TestClass();
        System.out.println("field value="+t.field);

        Integer j;
        // System.out.println("j = " + j); // illegal
        //if (j == null) System.out.println("OK"); // illegal
    }
}

Java automatically initializes fields, though not local variables, unless they are arrays, in which case they will be initialized. Except at night... (See Jane Griscti's Java reference for a great summary of Java's habits.) Java uses null to indicate "no value" for objects, but its undefined value is, well, undefined. You cannot even compile a program successfully if you attempt to use a variable without defining it first, even if you've declared it. See the sample code. The field may be accessed because it is auto-initialized; the local variable may not.