Question

Every time anyone mentions testing against undefined, it’s pointed out that undefined is not a keyword so it could be set to "hello", so you should use typeof x == "undefined" instead. This seems ridiculous to me. Nobody would ever do that, and if they did it would be reason enough to never use any code they wrote… right?

I found one example of someone who accidentally set undefined to null, and this was given as a reason to avoid assuming that undefined isn’t overwritten. But if they’d done that, the bug would have gone undetected, and I fail to see how that’s better.

In C++ everyone is well aware that it’s legal to say #define true false, but nobody ever advises you avoid true and use 0 == 0 instead. You just assume that nobody would ever be a big enough jerk to do that, and if they do, never trust their code again.

Has this ever actually bitten somebody where someone else assigned to undefined (on purpose) and it broke your code, or is this more of a hypothetical threat? I’m willing to take my chances to make my code marginally more readable. Is this a really bad idea?

To reiterate, I am not asking for how to protect against reassigned undefined. I’ve seen those tricks written 100 times already. I’m asking how dangerous it is to not use those tricks.

Answer 1

No, I never have. This is mostly because I develop on modern browsers, which are mostly ECMAScript 5 compliant. The ES5 standard dictates that undefined is now readonly. If you use strict mode (you should), an error will be thrown if you accidentally try to modify it.

undefined = 5;
alert(undefined); // still undefined

'use strict';
undefined = 5; // throws TypeError

What you should not do is create your own scoped, mutable undefined:

(function (undefined) {
    // don't do this, because now `undefined` can be changed
    undefined = 5;
})();

Constant is fine. Still unnecessary, but fine.

(function () {
    const undefined = void 0;
})();