null comparison expressions, even though linter software tends to
null as separate values. The
first comes up in many constructs in the core language—an
uninitialized variable, a parameter that wasn't passed, a missing
field in an object, or a call to a function that doesn't return
anything all have the value
null value has the ring
of a C null-pointer, and tends to be common in library interfaces—a
child-less DOM node has a
firstChild property of
getElementById with a non-existent ID gives you
null, and so on.
I have found the distinction between
undefined to be
mostly useless—a cognitive burden without merit.
The interesting distinction is usually between 'non-values' and actual values.
== null (or
!= null, as it may fit) pattern is...
typeof X == "undefined".
nullvalues, saving external code the bother of worrying what they are passing in.
_.isNulland similar helper functions, which I unexplicably see pop up in many projects.
So I've made it policy in my code, whenever possible (which is pretty
much always) to treat
undefined interchangeably when
accepting them as input. This saves both myself and the users of my
libraries one more thing to worry about.
(For output, I tend to stick to
null, so as to not force my sins on
the poor souls who have to code under the tyrannical eye of JSLint.)