Comment by aaron-lebo | Hacker News Reader

Comment by aaron-lebo | Hacker News Reader

Parent Full thread

1. Always use referential equality checks (triple equal `===`). In idiomatic JS you can also use double equality only when explicitly checking against undefined or null (foo == null). It's the only use of abstract equality that I find acceptable.

I've found this advice in guides and in codebases, but it seems unnecessary to me. The vast majority of equality checks are of the if (str == 'str') or if (n == 0) type. It's rare that you are actually comparing two objects of different types and when you are it's kind of nice to see === and know, otherwise it's just kinda ugly (kinda like const in languages, but we don't gotta hash that out here). There is a debate like this in the lisp community over eql and such. Similarly, isn't (foo == null) redundant? In most cases if (!foo) is what you are interested in and it's cleaner.

Is this incorrect? Would be cool to have it clarified. Have never actually run into a bug due to it, so not sure if the limitations of == are mitigated though coding style or what.

But in total agreement otherwise. Modern JS is really good, it's as productive as anything else, expressive, and once you know the quirks they are easy to avoid. Where JS has problems is inexperienced devs where they can code with var and for (var ...) monstrosities that date back to like 1996.

> Is this incorrect?

Yes it is. The reason for the deep equality check is not so much that you want the check on type, but because this way you avoid the entire giant class of errors caused by type coercion, just like in PHP. Think things like:

  function check_user_id(user_id) { return user_id == 1; }
  check_user_id('1 error detected');

It's obvious when you see the exemples, and is usually a bug somewhere due to a missing check, but in language such as this it can often causes deep errors yet stay unseen for months.

There is a reason why strict type hinting has become a most-wanted (and now beloved) feature of PHP, and of JS through language such as TypeScript: most of the time, you don't really care like you said if it's '1' or 1, but because it's supposed to be a number anyway it makes no sense to not force it to be one or error out.

In other words, it's better to trade "I don't want deep equality check most of the time" with "I don't want lax equality most of time".

To be fair, your example returns false in JavaScript, unlike in PHP.

The answer (in my opinion at least) is that yes `==` should be avoided, if for nothing else then simply because it's totally unnecessary and only adds a mental overhead.

I haven't found a use case where it would be necessary, and when it would seem it is, it's indicatory of code smell, e.g. badly formatted JSON responses.

Maybe a use case for abstract equality could be for comparing HTML data attributes (which all return strings by default using the web APIs). In this case it would be far better to abstract your HTML data attr wrapper to something like jQuery's .data method which will always return correct specific types rather than strings (e.g. data-bool="true" will return _true_ (bool) instead of "true" (string)). I believe many of JavaScript's old quirks are due to trying to interoperate with HTML better.

> In most cases if (!foo) is what you are interested in and it's cleaner.

In most cases yes, but there are cases where you simply want to check explicitly for undefined or null (e.g. does a variable or property exist or has a value, even if it's an empty string or 0). !foo means your variable isn't: an empty string, the number 0, the bool false, null or undefined.

It's also worth noting that `===` is not deep equality. It's merely referential equality (the equivalent of .is in other languages) for all non-primitive types.

e.g. [1,2,3] === [1,2,3] will always return false since the two arrays are different objects and point to different references. "123" === "123" will return true because they are both Strings (considered primitive types in JS).

Abstract equality will always fallback to strict equality when the types of the compared values are the same, but using strict equality everywhere avoids headaches that might come up during runtime.

Edit: I'm not sure why you're being downvoted, you're simply asking a question.

Great reply, thanks.

I think the issue is that you do want non-strict equality 90% of the time, but correctly identifying the 10% where you need strict equality is difficult and impossible to automate. So you end up weighing cognitive overhead and subtle type bugs vs an extra equals sign, which seems like an easy choice to me.

And I think the GP was talking about an existence check with the null comparison, like “did this function receive the argument false or no argument at all?”

> It's rare that you are actually comparing two objects of different types

Javascript is weakly typed, so it can be hard to say what types are involved in the comparison. Using strict equality covers the case where the type isn't what you were expecting, circumventing unexpected behavior.

I also don't actually find it ugly.

Reply on news.ycombinator.com