OK to use type coercion when checking for undefined/null?

Question

Is it acceptable to use type coercion (== instead of ===) to check for undefined/null?

What are the downsides? Is there a better way to check for undefined/null?

Clarification: I am looking for a statement that will check for both undefined and null.

test(null);
test(undefined);

function test(myVar) {
    if (myVar != undefined) {
        alert('never gets called')
    }
}

Answer 1

I'm going to attempt to address this question as objectively as possible, but it deals with some mushy "best practices" opinion stuff that can trigger people to forget that there's more than one way to do things.

Is it acceptable to use type coercion (== instead of ===) to check for undefined/null?

It's acceptable to write code however you see fit regardless of anyone who tells you otherwise. Including me.

That's not really helpful here, so let me expand on that a bit, and I'll let you decide how you feel about it.

Code is a tool that can be used to solve problems, and == is a tool within JavaScript code to solve a specific problem. It has a well-defined algorithm which it follows for checking a type of equality between two parameters.

===, on the other hand, is a different tool that solves a different, specific problem. It also has a well-defined algorithm which it follows for checking a type of equality between two parameters.

If one tool or the other is appropriate for your use-case, then you shouldn't hesitate to use the tool.

If you need a hammer, use a hammer.

But if all you have is a hammer, then everything looks like a nail, and this is the core issue with ==. Developers coming from other languages often aren't aware of how == works and use it when === would be appropriate.

In fact, most use cases are such that === should be preferred over ==, but as you've asked in your question: that's not true in this instance.

What are the downsides?

If you relax your standards for === and allow developers to use == you may very well get bitten by misuse of ==, which is why sticking religiously to === may be acceptable to some, and seem foolish to others.

if (val === null || val === undefined) {...

is not particularly difficult to write, and is very explicit about intent.

Alternatively,

if (val == null) {...

is much more concise, and not difficult to understand either.

Is there a better way to check for undefined/null?

"better" is subjective, but I'm going to say, "no" anyway because I'm not aware of any that improve the situation in any meaningful way.

At this point I will also note that there are other checks that could be performed instead of null/undefined. Truthy/falsey checks are common, but they are another tool used to solve yet another specific problem:

if (!val) {...

is much more concise than either of the previous options, however it comes with the baggage of swallowing other falsey values.

---

Additional notes on enforcement via linting:

If you follow the strictness of Crockford's JSLint, == is never tolerated, in the understanding that a tool that's "sometimes useful" but "mostly dangerous" isn't worth the risk.

ESLint, on the other hand, allows for a more liberal interpretation of the rule by providing an option to allow null as a specific exception.

Answer 2

== undefined and == null are both equivalent to checking if the value is either undefined or null, and nothing else.

As for "acceptable", it depends on who is looking at the code, and whether your linter is configured to ignore this special case.

I can tell you for sure that some minifiers already do this optimisation for you.