Christian Höltje

Christian,

> You say that "if (document.onclick != null) {" is "useless".  Checking
> against null isn't useless (though it should be done with '===' not
> '=='), though it is in that case.

Changed "Checking against null is a very bad thing to do." to "Checking
against null with inbuilt properties is a very bad thing to do.".

Of course, with custom objects where you have given known value types, it is
OK (though unless your custom object's properties have two possible values
that both equate to false when used in a comparator, and you need to
differentiate between them, the null check is still unnecessary). However,
the article was describing how inbuilt properties, or variables created from
them, are not cross browser compatible when it comes to uninstantiated
values, and checking against null in those cases is extremely harmful. I
hope the change makes this more clear.


Mark 'Tarquin' Wilton-Jones - author of http://www.howtocreate.co.uk/

Christian,

> As an aside...  I'd think that 'a !== null' would be faster than '!a'

To make them equivalent, that would be if(a) not if(!a). Though that makes
very little time difference when testing.

> since it doesn't have to do several checks to see what 'a' is.

A quick test shows this is not the case. Opera and Firefox give almost
identical times for each. If anything they have slightly better times for
the basic if(a). IE gives _much_ longer times for the !==null version,
possibly because it actually has to create a new null object to test
against, making it take twice as long as the if(a) version if 'a' is a
non-null and about 10% longer if 'a' is null.

The basic test is more efficient overall. In reality, I had run the test in
a loop 1000000 times for the times to become significant enough to test, so
it is unlikely that the differences will be a problem at all in real
applications. However, if you are testing against a large data set, it is
better not to use != null or !== null if a simple if(foo) test will suffice.

Tarquin