Firstly, yes, undefined is not a reserved word, and I shouldn’t have used the phrase, since it has a specific meaning, though my understanding of the nature of undefined I think was correct. My point was that as a property of the Global object, undefined is always in scope and therefore available for comparison. But now I think that wasn’t your issue with it, so my point was probably irrelevant.

I also take your point about this very distinction weakening undefined by making it possible (since it isn’t a reserved word) to redefine it by mistake, something I hadn’t considered. I also now see your original point quite clearly - it was, I’m afraid, more subtle than I gave it credit for.

Finally, I agree that it is better to check the arguments object for the number of parameters passed in, though it does make for less readable code if, say, you had a function declaration with 6 parameters and you wanted to check whether the sixth one had been passed in.

I still prefer my solution to your comparison to null because I think it makes its intentions clearer to someone coming to the code fresh, but otherwise I concede the point entirely.

Thanks for your comment. Since you’ve kindly pointed to the spec, I’ll refer to it in reply.

The spec defines ‘Reserved Words’ in section 7.5.1. undefined is neither a keyword nor a literal; so, according to the spec, it is not a reserved word.

I need to clarify my ’safer’ and ‘more logical’ statements. First, the ’safer’ claim:

There’s a school of coders who write if-conditions with literals on the left, to defend against accidental assignment caused by typo’s. For example: if (3 == index) { ... }. If they accidentally used one = instead of two, the code fails to parse, and the browser helpfully tells them exactly which line is in error. On the other hand, if they write if (index = 3) { ... }, the code parses, and runs, and may lead to errors that are substantially more difficult to track down.

This school of coders would write if (undefined == element), or, by mistake: if (undefined = element). Bang! Say good-bye to your ‘undefined‘ value…

When I say that null is more logical, perhaps I only speak for myself. A null value is defined in the spec as a …null, empty, or non-existent reference and I translate that to mean that you cannot refer to or access any properties of a null value. undefined isn’t defined so clearly, but it too has no properties.

You mentioned type coercion: type coercion is the reason why a null-check works as well as an undefined check in this case.

And finally, you should use the arguments object to check whether parameters have been passed in, not undefined checks (it’s perfectly legal to pass an undefined parameter into a function. Spot the difference between: alert() and alert(undefined))

(Final Note: arguments is no more a reserved word than undefined is, but arguments is initialised as part of the ‘Activation Object’ (section 10.1.6), and you need to work harder to break it.)

if (typeof row === “undefined”) return this.tab…

… which works in pretty much any JavaScript enabled browser.

Your suggested replacement code is neither safer nor more logical - undefined and null are not the same, and, while comparing an undefined variable to null using == will return true, it hides from the casual eye the type coercion the == operator silently performs. More importantly, a parameter whose value is null is very different to no parameter being passed in at all, two cases which would be treated the same by your code.