Hacker News Reader

Comment by snek | Hacker News Reader

I see a lot of comments here suggesting that == is okay to use if you know what you're doing or if the types on both sides match or if this or if that. Writing idiomatic code is all about being expressive and being explicit. Even in the most common case, testing for null or undefined, it's absolutely not clear what is actually happening or what the intent is. I write a lot of JS, and I've never had any justifiable reason to use ==.

View on HN

Depending on your conventions for null/undefined (another annoying wart of JavaScript), I think it often makes sense to treat `== null` as a special allowed case. In the code I work in, `== null` is strongly encouraged (but not required) as the way of doing null checks, and all other uses of `==` are disallowed by lint. Just like our other patterns and conventions, it's something people pick up reasonably quickly as they're introduced to the code, nothing tricky, just a little pattern that acts as a concise replacement to the `?` operator from CoffeeScript.

The alternatives are writing `x === null || x === undefined` everywhere (which might lead to people just picking one out of laziness, leading to bugs), doing things like `if (x)` (which we still do sometimes, but can lead to subtle falsy-related bugs if you're not careful), or to do careful bookkeeping of when variables might be null vs undefined. In my opinion, the null/undefined distinction is more cognitive overhead than the benefit it provides, so it's best to just check for both at the same time and never intentionally treat them as different. Given that mindset, I think the `== null` pattern is slightly unfortunate, but better than the alternatives.

exactly! `==null` and `!=null` are the only reasons I use it.

For those not aware, you can specify a rule in [js/es/ts]lint to allow only these cases.

My team checks for types, not for null.

`const isString = myVar => typeof myVar !== 'string'`

This is more reusable and more idiomatic in my opinion than null/undefined checks

This is especially useful if you are using TypeScript (or Flow I assume) because the type checker can give you an error at compile time. After performing the runtime check, TypeScript will know that null/undefined is not possible.

See this example https://goo.gl/AyoC3T

But then you have the problem that typeof null === 'object'.

Shouldn't that be called `isNotString`?

Agreed. The second you use `==`, now everyone else who encounters it has to do their own research to see if you indeed meant it.

It's like every time you defensively throw in a nil-guard just in case: everyone now has to go "wait, can nils really get this far into the system?"

You just start wasting the time of the people experienced enough to identify it as a potential problem.

Thank you, that was a well written summary of my thoughts.

I only ever use == to do “x == null”, to check if x is undefined or null, but not any other falsey value like 0.

that is the only good and handy use of it, yes.

yeah if I'm doing any kind of loose type-checking I make it explicit.

if (myNum === 2 || myNum === '2') {}

It's very easy for developers to mistakenly "see" the third equality symbol and get confused by the intent of the code.

In that sort of case I like to use explicit type casting, e.g.

    if (Number(myNum) === 2) {}

For me this also extends to using `Boolean(val)` instead of `!!val`, etc.; though I understand the appeal of those nifty one-liners, I think they cause confusion in many places and don't communicate intent nearly as well.

Reply on news.ycombinator.com