this post was submitted on 25 Jan 2024
667 points (97.6% liked)

Programmer Humor

19623 readers
2719 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] backhdlp@iusearchlinux.fyi 46 points 10 months ago* (last edited 10 months ago) (11 children)

I still don't understand the === operator

Edit: I think a more type strict ==? Pretty sure I understand the point of typescript now.

[–] SzethFriendOfNimi@lemmy.world 129 points 10 months ago* (last edited 10 months ago) (1 children)

So in JavaScript there’s the assignment

=

and the comparator is

==

Since there’s no types JS will do implicit conversion before comparison when using == in a case like this

if(false == '0'){
    //this is true
}

But with === it doesn’t. It means literally compare these

if(false === '0'){
    //this is false
}else{
    //so this will execute instead 
}

But this, however, will

var someState = false;
 if(someState === false){
    //this is true
}
[–] QuazarOmega@lemy.lol 68 points 10 months ago
> 1 == 1
true
> 1 == '1'
true
> 1 === '1'
false

(from node REPL)

Basically it's the real equals sign perfection

[–] frezik@midwest.social 46 points 10 months ago (1 children)

The short answer is that your language needs === when it fucked up the semantics of ==, but it's also too popular and you can't fix it without breaking half the web.

[–] marcos@lemmy.world 2 points 10 months ago

Or when it is something like Prolog, where equality is inherently a messy and complex concept.

[–] SmoothIsFast@lemmy.world 28 points 10 months ago

It's like the ==, but there's one more =

[–] kevincox@lemmy.ml 21 points 10 months ago (1 children)

JS's == has some gotchas and you almost never want to use it. So === is what == should have been.

All examples are true:

"1" == true
[1, 2] == "1,2" 
" " == false
null == undefined 

It isn't that insane. But some invariants that you may expect don't hold.

"" == 0
"0" == 0
"" != "0" 
[–] Feathercrown@lemmy.world 5 points 10 months ago (1 children)

One neat feature is you can compare to both null and undefined at the same time, without other falsey values giving false positives. Although that's not necessary as often now that we have nullish coalescing and optional chaining.

[–] kevincox@lemmy.ml 2 points 10 months ago (1 children)

I just tested and Terser will convert v === null || v === undefined to null==v. Personally I would prefer to read the code that explicitly shows that it is checking for both and let my minifier/optimizer worry about generating compact code.

[–] SzethFriendOfNimi@lemmy.world 0 points 10 months ago (1 children)

Try changing to const === variable. That’s most likely what’s it doing to minimize the risk of accidental assignment.

[–] kevincox@lemmy.ml 3 points 10 months ago (1 children)

Wut? This is an automated optimizer. It is not worried about accidental assignment.

[–] SzethFriendOfNimi@lemmy.world 1 points 10 months ago (1 children)

I agree it shouldn’t. But I’ve seen linters that automatically change it since they seem to be forcing practical conventions sometimes.

[–] kevincox@lemmy.ml 3 points 10 months ago (1 children)

Linters and minifers are completely different tools.

[–] SzethFriendOfNimi@lemmy.world 3 points 10 months ago

Good point. That’s what I get for shooting from the hip.

Thanks!

[–] Mikina@programming.dev 18 points 10 months ago* (last edited 10 months ago) (2 children)

It's also important if you're checking hashes (at least, it was - if you're using correct hashing algorithm that isn't ancient, you will not have this problem).

Because if you take for example "0e462097431906509019562988736854" (which is md5("240610708"), but also applicable to most other hashing algorithms that hash to a hex string), if("0e462097431906509019562988736854" == 0) is true. So any other data that hashes to any variantion of "0e[1-9]+" will pass the check, for example:

md5("240610708") == md5("hashcatqlffzszeRcrt")

that equals to

"0e462097431906509019562988736854" == "0e242700999142460696437005736231"

which thanks to scientific notation and no strict type checking can also mean

0^462097431906509019562988736854^ == 0^242700999142460696437005736231^

which is

0 == 0 `

I did use md5 as an example because the strings are pretty short, but it's applicable to a whole lot of other hashes. And the problem is that if you use one of the strings that hash to a magic hash in a vulnerable site, it will pass the password check for any user who's password also hashes to a magic hash. There's not really a high chance of that happening, but there's still a lot of hashes that do hash to it.

[–] darcy@sh.itjust.works 10 points 10 months ago

that is terrifying

[–] frezik@midwest.social 1 points 10 months ago

If you're checking passwords, you should be using constant time string checking, anyway.

More likely, you should let your bcrypt library do it for you.

[–] Limitless_screaming@kbin.social 18 points 10 months ago

== but for JavaScript. What you don't understand is the == of JavaScript.

[–] Bougie_Birdie@lemmy.blahaj.zone 6 points 10 months ago (1 children)

The other comments explains it in pretty good detail, but when I was learning my teacher explained it sort of like a mnemonic.

1 + 1 = 2 is read "one plus one equals two"

1 + 1 == 2 is read "one plus one is equal to two"

1 + 1 === 2 is read "one plus one is really equal to two"

And you hit the nail on the head, is that === is type explicit while == is implicit.

[–] bobbykjack@programming.dev 3 points 10 months ago* (last edited 10 months ago)

I'd use something like:

= becomes

== equals

=== is identical to

It's funny how everyone thinks "equals" in this context should be "identical to" when, in normal language, it doesn't really mean that at all!

[–] clb92@feddit.dk 4 points 10 months ago* (last edited 10 months ago)

Like == but more strict. The == operator will do type conversion, so 0 == '' will actually be true, as an example. Sometimes (honestly, most times) you may want to compare more strictly.

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

[–] ShortFuse@lemmy.world 4 points 10 months ago* (last edited 10 months ago)

You don't need Typescript, you need an linter (eslint).

=== is your basic equality like most languages. == will implicitly cast type.

The breakdown is here: https://262.ecma-international.org/5.1/#sec-11.9.3

Modern JS says to never use == unless you're comparing against null or undefined.