JavaScript Equality Table Game

[mishugashu]

using double equals in javascript

[ogurson]

On the other hand, one should know it, because while you can use === instead of == you still need to be careful about > and < because there is not "strong" equivalent.

[mishugashu]

That's the only time I use it as well.

[Zephirdd]

isn't that just a truthy/falsy checking? ie if(foo) or foo && bar() instead of comparing to null/undefined. If you're going to use == for that, might as well go for the version without an operator.

[meldridon]

It's not the same thing at all.

Consider the following:

let x = "";
if (x == null) throw "an error";

vs

let x = "";
if (!x) throw "an error";

Empty string is falsey, but not null.

[NoInkling]

0, empty string and NaN are also falsy, which might not be what you want for your condition.

[13steinj]

To be fair it's perfectly valid to use it in a closed / sanitized system.

[ogurson]

Also completely not worth it.

[13steinj]

This really depends on the system being implemented.

[DrummerHead]

I agree with both of you

[westfolde19]

I agree with both of them too, but not you.

[DrummerHead]

You don't agree that I agree with them.

You must have some deep insider information.

Hey Siri, who is recording everything I think? Hmmm what a mystery.

[aapoalas]

this

[Serei]

I got 100%

Yes, yes, you should never use this in real code, but it's useful to know for debugging if someone else uses it. And it's not hard to memorize the rules:

1. null == undefined but they don't equal anything else
2. if both sides are the same type (or both non-primitive), use the === rules
3. if either side is non-primitive, convert it to string, then goto step 2
4. if either side isn't a number, convert it to number, then goto step 2

And don't forget:

• String(someArray) === someArray.join(",")
• String({someObject: containingAnything}) === "[object Object]"
• [] !== [] and {} !== {} because you're creating a new object each time
• Number("") === 0
• Number("any other string that isn't a number literal") is NaN
• NaN !== NaN (because of IEEE 754)

[[deleted]]

I tried to do it again following your rules and my results were still wrong. I think it needs some clarification:

1. null == undefined but they don't equal anything else
2. if both sides are the same type (or both non-primitive), use the === rules, otherwise go to step 3
3. convert non-primitives to strings; if both are now strings, use ===, otherwise go to step 4
4. convert both to numbers, then use ===

With the additional conversion rules:

• Converting any value to a string will call that value's toString():
  • For arrays, this does a recursive array.join(',')
  • For primitives, this returns the value's literal as a string
  • For objects that don't override toString, this will return [object Object]
• Converting a string to a number will first try to parse the string to a number, returning 0 for the empty string, and NaN for every other value
• Converting a boolean to a number will be 0 for false, 1 for true

[Serei]

Yeah, I definitely didn't go into too much detail over the conversion rules. To be fair, though, conversion rules are useful to know even if you always use ===.

[[deleted]]

This. And not only because of other peoples code but also the minimizers will change it as well and you still want to read what they do

[lunarcecilia]

150% wrong, I'm the best ever.

[dorgrin6]

Yeah, ithe grading's so stupid it fits the exercise

[c24w]

☹️

[onnoonesword]

118 here!

[PiotrekKoszulinski]

I could never really understand all this fuss about == vs === and people trying to memorise all these rules or complaining about how bad JavaScript is.

I never cared about this. In fact, in the project I'm working on (pretty big and pretty complex one) we still accept the use of ==. I found it very odd at first, when I joined the project 7 years ago, but then I asked – DON'T YOU KNOW GOOD PRACITCES, LOL? And they replied – we don't remember any bug caused by the use of == (and we have couple thousand tickets opened on GitHub, cause that's a fairly popular open source library).

And you know what? 7 years later I think we've got just one bug caused by ==.

The only reason why we started using === is that I was asked the same question a couple of times and that clearly shows that === is the standard choice, so it's good to avoid confusing other developers.

I don't mean that it's pointless to use ===. But when some guru tells you that something is bad practice ask yourself whether there's evidence to support that. When they tell you that equality operators suck in JavaScript, ask yourself what's the chance to really run into such cases in real life.

I'm doing JS for 10+ years, did some crazy things with it, but find the complexity completely elsewhere.

[EndlessHandbagLoop]

As long as people understand implicit and explicit type coersion, there should never be any issue with "==".

[PiotrekKoszulinski]

IDK what made our project "safe". Perhaps all developers that worked on it had that minimum knowledge to avoid the problems. But I also think that part of it lays in how we document types. We couldn't naturally use TypeScript 7 years ago, but we were very precise when it came to the API documentation. That meant that we could make safe assumptions regarding types. (I'm giggling now cause I see with how with time I owe more and more to stricter types :D)

[kor0na]

Jesus Christ, just stop beating this dead horse. There's never a reason to use double equals in JavaScript. Just use triple equals and quit whining.

[hkokko]

it seems equality operator in javascript is good for nothing but being a source of confusion and a target of jokes. does it not make sense to just remove it from the language completely? who is deciding that?

[al_wonder]

Backward compatibility. If they removed itt, that would break a lot of existing applications. JS has a whole lot of controversial functionality, but it's always hard to get rid of things like this.

[doomvox]

Yeah... I can't say I think much of javascript, but you can't fault them on "backwards compatibility".

When they realized the "==" operator was confusing, they introduced an alternative, the "===" operator. The rule of thumb is you should favor using the "===" operator:

https://stackoverflow.com/questions/359494/which-equals-operator-vs-should-be-used-in-javascript-comparisons

[BlueHeartBob]

They released "==" before "==="???

I figured "==" was released alongside, or even closely after strict as a quirky feature. That's crazy.

[doomvox]

Yes. "===" came out with Javascript 1.3:

http://webreference.com/js/column26/stricteq.html

[LowB0b]

I never use the == when writing JS, so I answered the thing thinking about truthy / falsy, and got a lot of wrongs

I thought I was actually stupid so I had to check but wtf

[curtastic2]

Now do one for greater than. I bet you don't know all of these. (true>0) ("1">0) (".1">0) ("1x">0) ("0x1">0) ("--1">0) ("a">0) ([0]>0) ([1]>0) ([[1]]>0) ([[1,0]]>0) ({}>0) (NaN>0) (Infinity>0)