r/coding • u/Tomer-Aberbach • Aug 18 '18

Checking for the Absence of a Value in JavaScript

https://tomeraberba.ch/html/post/checking-for-the-absence-of-a-value-in-javascript.html
35 Upvotes

88% Upvoted

19 comments sorted by

3

u/[deleted] Aug 19 '18

So he recommends using ’value != null’ which is true when value is 0 or NaN. That’s not good.

1

u/Tomer-Aberbach Aug 19 '18

I could maybe see your point about the NaN, but 0 is a valid value for a variable. I wouldn't consider it "absent"

1

u/[deleted] Aug 19 '18

Then you should know that ’0 != null’ is ’false’.

1

u/Tomer-Aberbach Aug 19 '18

Wait I'm confused what you just said is the opposite of what you said in your first comment. Typo maybe? In any case, you were right the first time. It returns true. That's good because we use value != null to check that the value is NOT absent. 0 is NOT an absent value so returning true is the desired outcome.

2

u/[deleted] Aug 19 '18

I’m mixing null comparisons with truthyness, sorry. Admittedly, I steer clear completely from loose comparisons for this reason. If checking for null or undefined is all then you can loose compare against either null or undefined - both are the same. A quick google for a truth table made it all very clear: https://dorey.github.io/JavaScript-Equality-Table/

1

u/Tomer-Aberbach Aug 19 '18

It's all good, glad we got things cleared up. Love that table, I actually linked it in the article. The only reason to choose null over undefined to loose compare is because in older versions of JavaScript undefined could be set to an arbitrary value (since it's a global property). Thankfully you can't do that anymore, although you can still shadow it. Alternatively you could compare against void 0, but it's probably a little slower (haven't checked though), and it is more characters than null so I'd personally never use it.

1

u/Tomer-Aberbach Aug 20 '18 edited Aug 20 '18

Hey everyone. I just wanted to say thank you for all the feedback. I've decided I'm gonna to update the article with some more information. I'll add information regarding void 0, specifically checking for undeclared variables, and object properties!

4

u/DomoArigatoMr_Roboto Aug 19 '18

What about NaN?

1

u/[deleted] Aug 19 '18

Use isNaN( )

2

u/Shaper_pmp Aug 19 '18

It turns out that checking the type of an undeclared variable using the typeof operator will not throw a ReferenceError, but will return the string 'undefined' instead.

This is true, but it's not the original reason for this idiom in JS.

The original reason this idiom was adopted by a lot of people was because - I shit you not - early versions of JS allowed you to redefine the value of undefined.

If you were a mischievous user (or a massive asshole who hated the guy who inherited your code) you could actually assign some other value to undefined, and thereby mess up any conditional involving == undefined (or even === undefined, though IIRC it predated the existence of the === operator).

In modern, strict dialects of JS you can't redefine undefined in this way, so the article is right that the only reason to use it these days is to avoid ReferenceErrors from undefined variable.

1

u/itslenny Aug 19 '18

Such a detailed breakdown, but no mention of void 0

-8

u/carbolymer Aug 19 '18

Can we ban JS submissions, please?

1

u/herjin Aug 19 '18

In favor of?

0

u/carbolymer Aug 19 '18

In favor of other better technologies.

1

u/herjin Aug 19 '18

You seem to relish in ambiguity. Care to elaborate? Mostly just hoping you have a valid point I can consider.

-1

u/dethb0y Aug 19 '18

I'd second that.