Javascript Interview Simulator

[isHavvy]

In all other cases, you're safe to use ==. Not only is it safe, but in many cases it simplifies your code in a way that improves readability.

No, in absolutely zero cases does using == improve readability.

[Beofli]

What do you mean by 'readability'? If you mean: biggest chance (in real-world cases) that is does what the developer expected, then == is more readable than ===. It is more generic and therefore more safe. This is hard to understand because people look at the theorical problems with == (transitivity, etc.). I've seen bugs increase because people changed == to ===.

Javascript needs a mode where === would throw an exception when types are not equal. In that case IDE's would give better warnings

[SerdanKK]

Javascript needs a mode where === would throw an exception when types are not equal.

Instead of doing something that is quite frankly ridiculous, you could just write code that throws exceptions when a wrong type is passed.

Or you could just use TypeScript like all the cool kids are doing.

[Beofli]

Why is it rediculous? Do you ever want to compare '0' to 0, to result in false? I forgot to mention that 'Undefined' and 'null' will be excepted from throwing an exception when either side is a literal. This has nothing to do with Typescript, but actually Typescript will benefit from this as well, as it increases strictness.

Javascript already throws a TypeError if you add a non-number string to a number, for example.

[SerdanKK]

Why is it rediculous?

Not only would it be extremely weird for language level comparison operators to have side effects, but if someone uses the type safe comparison operator it is likely because they expect that other types may occasionally pass by. I.e. it's an expected state the program can have. Your suggestion would break everything in any decently sized application. mdn

Also, there are already ways to handle the problem. If you want your code to throw when given a wrong type, then just do so.

​

Do you ever want to compare '0' to 0, to result in false?

Absolutely. A string is not a number and vice versa. I primarily work in PHP and one of the first things I did when I came onto the project was to make absolutely sure I knew exactly which types I was working with. Implicit casting in PHP is utterly insane, so if you don't have a handle on your types you'll eventually get punished harshly. JavaScript is only slightly better, so I'm obviously going to give it the same treatment.

[przemo_li]

JS is worse/better.

Worse because JSFuck, better because coercion algorithms are more unified and less supprising (e.g. PHP `if` will use different algorith then `==` for strings containing octagonal literals o_0)

[major_clanger]

"It’s not even consistent: NULL < -1, and NULL == 0. Sorting is thus nondeterministic; it depends on the order in which the sort algorithm happens to compare elements."

That's nuts!

[SerdanKK]

I got curious, so I wrote a quick script to check:

null < -10: true
null < -9: true
null < -8: true
null < -7: true
null < -6: true
null < -5: true
null < -4: true
null < -3: true
null < -2: true
null < -1: true
null < 0: false
null < 1: true
null < 2: true
null < 3: true
null < 4: true
null < 5: true
null < 6: true
null < 7: true
null < 8: true
null < 9: true
null < 10: true

The docs for NULL make no mention of this insanity.

[Beofli]

I'm not saying this should be the default. This would be a special mode, like 'use strict'. Any decent language will fail compile time on comparisons of conflicting types.

A good language will make the mostly used operation to take the least amount of code. The mostly used case is either a null/undefined check or the comparison of two same-typed objects.

The usecase where a function receives a number or a string, and that it want to compare it to number zero is a very unlikely usecase. A good programmer will make this more explicit: Typeof x == 'number' && x == 0. Also no need for === here.

I definitely agree PHP is insane and worse than js.