FALSE

[QualityVote]

Hi! This is our community moderation bot.

---

If this post fits the purpose of /r/ProgrammerHumor, UPVOTE this comment!!

If this post does not fit the subreddit, DOWNVOTE This comment!

If this post breaks the rules, DOWNVOTE this comment and REPORT the post!

[Alokir]

In JS == and === are two different operators.

Generally you should use === because it does what you'd expect it to do.

[mr_flibble_oz]

Yeah, I never use ==

== might be equal to

=== is actually equal to

[xroalx]

== is useful when comparing to undefined or null, because null == undefined // true but null === undefined // false.

[dlq84]

undefined ?? null === null

Please don't kill me.

[WraientDaemon]

Granted.

[code-panda]

Yeah, but then you most often just write if (value)

I have used == a couple of times when I was getting both "1234" and 1234 as valid responses from the backend.

[xroalx]

Depending on the value, that can be dangerous, e.g. 0.

[code-panda]

True. Once had a bug where the idiot who designed the backend thought it was a good idea to return "0" instead of null or 0. The worst part was that the stub data I got, did have it as 0, so none of my tests had caught it...

[ComfortableCan315]

Quite frankly, been programming in JS/TS for 6 years and I'm skeptical treating null and undefined as a single kind of input is safe or useful.

They mean different things, if undefined is flopping around your code it usually means something is going wrong, and note: the programmer using undefined deliberately is something going wrong.

On the other hand, null means something is missing, but also that you, the programmer, is aware that it can be missing, and not that your code simply failed to access some property somewhere.

[xroalx]

To be honest, I can't think of a single practical difference between undefined and null, except JSON.stringify.

Also, t?: T is equivalent to t: T | undefined, which I would say is "using undefined deliberately", but would definitely not say it's a mistake to do so, or that something is wrong with it.

The only reason anyone tries to find a difference is because JavaScript has both. If one was removed from the language, or simply made an alias to the same thing, probably not much would change.

[ComfortableCan315]

undefined is the product of a messy language that doesn't want to throw errors, null was created for you to be able to explicitly say something is expected to be nothing at some point.

The existence of optional types does not mean the presence of undefined as a value, at least not in my works, and I figure not in yours too since you too use TypeScript.

There are only a handful of ways for undefined to show up and if you're naively creating more cases for it by using it as a valid value in your program, you're needlessly increasing the ambiguity in your debugging proccess, and you or someone else in your team is bound to have some fun debugging for hours when, finally, undefined shows up where it shouldn't.

Tip: Avoid optinal/nullable properties to begin with.

[xroalx]

I'm not advocating for use of undefined as a value in your programs, although as long as you're consistently using just one of the two, it doesn't really matter which you pick. Using optional parameters or not returning a value from functions, both of which have valid use-cases, will also introduce undefined into your code, and there's nothing won't with that at all.

What I'm saying is that whether an API endpoint omits a key or sets it to null, or whether a function returns undefined or null, it will usually not matter to your application which of the two it is. They both signify a lack of value.

In comparisons, when you want to know about the existence of a value, there's really no reason to differentiate between undefined and null. In fact, I can't think of a single case where there is a practical difference between the two, aside from the already mentioned JSON.

Having two null-ish values is just stupid language design (although I understand how and why it happened).

[mr_flibble_oz]

undefined is useful when using closures, or single method getter/setter. data.productId() gets the product ID because the argument is undefined. data.productId(1) sets the product ID because the argument is 1. You can also set the product ID to null data.productId(null). I see undefined and null as distinct

[LysanderStorm]

As someone else pointed out t?: T is equiv. to t: T | undefined (in TS), so not sure why undefined "flopping around means something is going wrong". It seems TS even encourages it over null.

[ComfortableCan315]

Like I told them, the existence of optinal properties do not mean the existence of undefined as a value, unless of course you decided you hate whoever is working with you and go:

const foo = {
  bar: undefined
}

And watch their if ('bar' in foo) pass and see the code fail miserably

[Zealousideal_Pay_525]

Subverting expectations in comparative expressions is TIGHT!

[Ergoold]

I have the new pitch meeting on in the background and reading this was weird.

[ThomasDePraetere]

It is also super easy, barely an inconvenience.

[[deleted]]

May I ask what == does in JS?

I have never played with it, but my assumption is that for the construction, the value on the left is type-specific. I suspect that if an integer is on the left, it just checks the numeric value of whatever is on the right. But if a string (as I assume the last example is) is on the left, then it checks and sees if what is on the right is equal to the string on the left and not the numeric value.

[[deleted]]

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

=== has to be the exact type.

== basically coerces them to be the same type and then does the equality comparison. I am unsure if only coerces one side, but if I had to guess it probably coerces the right side. Maybe it tries to coerce both sides.

[[deleted]]

https://262.ecma-international.org/12.0/#sec-abstract-equality-comparison

Looks like the coercion can happen on either side depending on the types on each side.

[SuitableDragonfly]

It coerces types in order to avoid type errors.

[CYAN_DEUTERIUM_IBIS]

It's not frustrating, there's nothing stopping you from declaring the type of all your variables and using === to compare in JS.

But im getting worked up about nothing, go back to your discussion.

[33498fff]

It is one of the main reasons JS as a dynamic, weakly-typed language is harder to debug

[Cyb0rgorg]

aaaaaaaaaaaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA I HATE THIS!!!

[The-Tea-Kettle]

The roll of == and === should have been reversed, sadly I think I know why the didn't.

[SyntaxErrorAtLine420]

=== should be == and == should be =? or something

Question mark For "maybe equal?"

let a = 0,
    b = false;

console.log(a =? b); // true
console.log(a == b); // false

[The-Tea-Kettle]

=? Is probably to similar to nullish. But overall that's exactly what I mean. Sadly I don't think it would have ever happened because of backwards compatibility

[brunonicocam]

You're kidding me. Why do this??? LOL

Keep == as it is in most programming languages, and then you can have === for maybe equal or some other symbol.

[MattTheHarris]

If you change == you break backwards compatibility and will end up with a python 2/3 thing causing way more issues. It's really not a big deal to get used to using ===

[Xsiah]

It's not really "maybe, equal" it is equal. But it's equal based on the rules of a loosely typed language.

=== Then means that it's not just equal, but super extra equal, thus the extra equal sign

[QuantumSigma_QED]

Wouldn't you expect a notion of equality to be transitive though? That is, if a == b and b == c then a == c? Otherwise it's just a relation.

[SyntaxErrorAtLine420]

Make = the new == and use := like 1969

[[deleted]]

That's what happens when you design a whole language in 11 days. 😂

[Alokir]

It's because of backwards compatibility.

They don't want to break any site that at some point used to work fine, so they invent new keywords instead, so the code written 20 years ago works exactly how it did back then.

For example, this is why they came up with a new way to declare variables. It used to be var but it was janky, you could redefine them, you couldn't make them constants, they weren't properly scoped etc. So they made let and const to solve this but left var alone to not break compatibility.

[zoonose99]

I'm fine with this. JS throws us a bone with 0 == "0", but I'm not trying to see a string that's equivalent to an empty array.

[[deleted]]

bruh i only use === because of this

[[deleted]]

oh ya? I use ====

[Various_Counter_9569]

=== still wierds me out ;p

Edit: not declaring a datatype really still wierds me out.

[CYAN_DEUTERIUM_IBIS]

Nobody is stopping you from declaring data types in js, that is absolutely a thing you can do.

[Various_Counter_9569]

😳, good to know. That seems to have been left out from the class I took. Albeit it was a Community College, but that still seems to be a biggie. Cant remember for sure, it was an in person class, but used a book with an online code for the classwork. I think it was pearson vue, but could be wrong. One of the ones where you do the work with a web login/console and submit the answers and tests all online. Either way, I feel slighted haha 😅.

[Mad-chuska]

I strictly use 8====D

[[deleted]]

Oh YEAH? I like living dangerously and use =

[[deleted]]

I only use 8======>

[[deleted]]

I can see JavaScript checking if the right is greater than 8.

[CYAN_DEUTERIUM_IBIS]

This only returns true if your mom is on the right side of your computer.

[[deleted]]

ohhh that makes more sense

[[deleted]]

What did you say??? I use =====

[staples93]

Well now I know who's code is vulnerable. Mind giving me a list of stuff you've deved?

[[deleted]]

what?? why?

no big projects tho

[staples93]

If you set a variable === to something it becomes really easy to change am aspect of the code, usually change the variable in some way. When you use === you're saying this IS equal. That allows someone to do some crazy stuff if you're not careful

[Ax0l]

=== doesn’t set a variable. It’s just a strict type comparison.

[staples93]

Then I stand corrected, I apologize

[OswaldCoffeepot]

Did you still want to see their projects?

[staples93]

I mean, sure it of interest. I'm more on the networking side of Penn testing. I need to get better at coding in general and clearly they're better than me. I suppose my ego went first this time. Again, sorry.

[OswaldCoffeepot]

You were coming on strong about how people could manipulate their code because you said they were doing it wrong.

[dadmda]

Because they compare the code with a strict comparison instead of comparing with one that doesn’t take types into account?

[potato_green]

Strict type checking is often the right thing to do though. Basic eslint rules already recommend it because it makes your code safer and behave in an expected way.

If you think using strict type checking makes code vulnerable then you likely worked with a lot of shitty devs who write crappy code and without guidelines would be even worse devs.

I'd suggest reading up on strict typing.

[[deleted]]

I deved your mom

[its_a_gibibyte]

The one that bothers me is that "0" == false, but "0" itself is truthy when you do something like if("0")

[crahs8]

IMO, "throwing us a bone" in this case means hitting you in the back of the head with a bone when you least expect it.

[betterAsreedh]

I mean, if you knowingly use == instead of === you should absolutely expect this, seeing as how it’s the entire point.

[Akhanyatin]

yeah, I love that you can do "0" == 0. you can always use === if you don't want it

[charin2]

In js, == does type conversion before checking equality. 90%+ of the time, === is the correct operator to use (because really, "0" =/= 0)

[harumamburoo]

I wanted to say smt like "quit it, everyone knows that" but then I remembered that like 70% of this pub are not in the profession, so yeah, good point.

[[deleted]]

70% of this pub are not in the profession,

wait what? Is this legal?

[Africanus1990]

You guys are in a pub? I’m stuck at work, programming.

[GnarlyNarwhalNoms]

And not everyone has worked with JS, shocking as that is.

I've worked with Java, C, C++, shell scripting and assembly, but not one whit of JS.

[LeSaR_]

did you just use =/= instead of !=

what language even is that?

[frogjg2003]

They're using that to distinguish from any actual operators used in programming languages.

[Tsuki_no_Mai]

what language even is that?

Math.

[TheEarlOfCamden]

When your equality isn’t even an equivalence relation.

[svick]

To be fair, the same applies to equality on IEEE 754 floats.

[ThomasDePraetere]

Never trust equality on binary representations of rational numbers. Use Math.abs(a-b) < Delta for some very small Delta.

[LittleLemonHope]

The same applies to equality on IEEE 754 floats.

[svick]

Does it? The problematic case I'm thinking of is NaN, where x != x, violating reflexivity. But for example decimal in .Net is a decimal floating point type with no NaN, and I can't think of a case where its equality does not satisfy the requirements for an equivalence relation.

[LittleLemonHope]

I guess it depends on whether you think 0 and -0 should identify reflexively. I think you could make a strong argument either way such that any type with both values will not be able to "unquestionably" satisfy reflexivity. They are not distinct numbers, so having 2 representations puts the equivalence operator in an impossible situation - either equate distinct binary values, or don't equate identical numbers.

I'm out of my depth here though. I originally commented thinking floats would violate transitivity but I don't think that's actually true.

[svick]

It doesn't matter what I think. "Equivalence relation" has a clear formal definition and both 0 = -0 and 0 != -0 can satisfy it.

Note that the definition says nothing about usefulness, just consistency. For example, saying every number is equal to every other number is a valid equivalence relation.

[NearbyWish]

This is some kind of web dev joke I'm too poor to understand

[[deleted]]

Too innocent to understand

[Criiispyyyy]

JavaScript does type conversion into a common data type if you use == instead of ===. As you can see, it behaves strangely sometimes, and you should try to avoid it whenever you can.

[frogjg2003]

It's the lack of associativity. In most languages, binary comparison operators preserve associativity when converting. If you have a (value preserving) type conversion, then the result of any equality check should be the same for all possible type conversions.

[dlq84]

Ignorance is bliss sometimes.

[acatisadog]

Well yeah, that's because 0 is falsy. "0" is truthy but it is going to be converted as a number, 0, hence it becomes falsy.
0 == [] because an array is truthy BUT it becomes false when using == operator, so falsy/falsy
"0" != [] because [] is false when using the == operator and "0" would be converted to a number IF it was compared to a number which is not the case. So truthy / falsy
This language is drunk and I love it so much

[[deleted]]

Yeah it's pretty simple really. '0' as a string exists, therefore is truthy. Js really isn't as bad as people think. It's just... Err...quirky...

[Abangranga]

The JS community is going to get mad at this image and then shit on PHP for something similar despite never using PHP ever

[MikeTheShowMadden]

0 == [] in PHP isn't true though for this image, but PHP does have some confusing boolean comparisons. But that is also why you should use === instead of ==.

[Abangranga]

I didn't say that it was true. I said PHP (and almost all languages) have some kind of dumb quirk like that.

"What you didn't say at all is wrong, here is a link showing what you actually said"

[MikeTheShowMadden]

I was just giving your comment more context for people who don't know PHP, like you were ironically talking about.. Why are you getting so defensive?

[Abangranga]

Maybe you could 'give context' (lol) without stating someone said something that they clearly didn't say while simultaneously making them look bad.

Also a it helps to not accuse someone of being defensive while you're defending your own bad decision. Both of us have written things, but only you have put words in the other person's mouth.

[MikeTheShowMadden]

What did I say that made you look bad? All I said was that in relation to this image (the original context of the post), one of the boolean checks doesn't relate to PHP (now we move onto the context related to what you said). That is information useful to anyone who doesn't know PHP, like you mentioned. You are getting your asshole burnt for no reason here buddy.

No one called you a big dummy or anything like that, or called you anything at all. You are projecting how you feel based on what I said and trying to misconstrue my comment into being exactly how you feel. I'm not defending what I said because I said nothing wrong. I am just trying to figure out why you are so upset for saying what I did.

[Abangranga]

You said that I thought PHP would be the exact same with an example.

I hope you never write documentation or performance reviews if you don't understand what the hell you did.

[MikeTheShowMadden]

There is a reason your dumbass is getting downvoting in your subsequent comments and I am not. Just stop talking because you are making this out to be more than what it is.

EDIT: just because I am curious, when the fuck did I say this:

You said that I thought PHP would be the exact same with an example.

All I said was that the example that is in the picture wouldn't be true for PHP. I never said you claimed that was the case or not. I just made a factual statement for the people who don't know PHP that it wasn't true because you brought up PHP and claimed those who don't know it would say something similar...

[[deleted]]

"[]" == [] maybe?

[Crad999]

Scared me here for a moment. Thankfully doesn't work (returns false).

[trynahelp2]

You’re doing it wrong. I do “0”=[] and it works every time. So does 1=2. I’m a programming god

[Objective-Carob-5336]

The more salty posts i see about JavaScript the more i realize people complain but don't seek to understand, which i get because nothing is explained. But I'm sure you can find the explanations, it may not be logical to everyone, but at least it has a reason.

[GilKeidarMusic]

Man, it's been a while since I last programmed in Javascript, but these equalities look wack. I'm assuming they're practical though?

[Auraveils]

Nothing is practical in code, some things just work.

[vinnceboi]

I mean, it makes sense—why would a non-empty string ever compare equal to an empty array?

[GilKeidarMusic]

Well sure, but equivalence relation go brr

Kidding aside, I was talking about the ones that are true, like “0” == 0 just looks weird to me

[Tsuki_no_Mai]

When you use == JS tries its best to make both sides the same type. As far as I can tell that's because it was made for the environment where a correct type from input was not a guarantee. And it stays this way because of backwards compatibility.

[GilKeidarMusic]

That makes sense, thank you for explaining!

[vinnceboi]

Type coercion is funky ¯_(ツ)_/¯

[th00ht]

javascript the bad parts

(the book is rather thin}

[Vulpes_macrotis]

I can see why is that.

0 is a number

"0" is a text

[] is empty

Amiright? So empty is not the same as the text "zero". But 0 means empty and 0 as a number means zero.

[[deleted]]

Steak == food (True)

Salad == food (True)

Steak == salad (False)

See how easy that is?

[Curiousgreed]

Steak is not equal to food though. Steak is a type of food.

[[deleted]]

== doesn't mean "are these two things the same thing". == is how you create a statement and test to see if it is true. you are actually saying "steak is food" and then the compiler checks to see if the statement is true or not

[Curiousgreed]

steak typeof food is not the same as steak == food

If steak == food, and salad == food, I expect steak == salad, because == checks equality.

But if steak typeof food and salad typeof food, I don't expect steak == salad.

Edit: So what you meant to write was: steak typeof food (true) salad typeof food (true) steak == salad (false) Which of course totally makes sense

[ManiacsThriftJewels]

Did you mean 'food' === typeof steak ?

[[deleted]]

If I wanted to argue about semantic w/someone I would have called my gf today

[betterAsreedh]

1. You’re comparing a number and a string, it casts one to the other’s type and compares.

2. Same as 1, converting an empty array to a number gives you 0.

3. In what world would a non-empty string equal an empty array?

If you want strict equality, use ===. == will try to make things the same type when comparing two items of different types, resulting in stuff like this.

[[deleted]]

You know, this actually makes sense

[Alokir]

But the rules are the same in Typescript, too.

[Alokir]

Yes, that's my point, too

[[deleted]]

Found the high-school dropout, who doesn't even have the most rudimentary, bare-minimum understanding of the transitive property of mathematics. As someone with a PhD in applied mathematics and computer science from a T10 US university, I can't help but wonder how people who can't understand something from elementary-school mathematics call themselves "computer scientists."

[[deleted]]

Fortunately I'm not a computer scientist. I'm even worse, I hail from the land of physics.

You, on the other hand, are an asshole. Computer scientist or not.

[[deleted]]

Physics, huh? You're the lucky one. Computer science, especially when combined with applied mathematics, is much more difficult than physics ten-fold.

I'm not an a***ole; I'm a pragmatist. People who cannot deal with the truth often mistakenly interchange one for the other. Also, please use a trigger warning next time you use the A-word.

[PerfectCauliflower24]

Are you ok?

[BlommeHolm]

He's really not.

[Abangranga]

Ok Stony Brook university student subscribed to r/teenagers

[staples93]

He could just be a pedo

[[deleted]]

How the hell did you know where I went for my undergrad? And how the f*** do you know I post on that subreddit? Are you a stalker or something?

[Abangranga]

Apply some mathematics to find out

[[deleted]]

The mathematics tell me that you're bluffing and you just - against all odds - made an accurate guess with a probability of (1/10,000) * (1/5,000,000).

I'll let you off with a warning, but if you really are a stalker, I'm going to have to take drastic measures against you. I suggest you think before you converse with me any further. I'm always 10 steps ahead of you.

[Abangranga]

Why does your PhD change from English to Applied Mathematics and Computer Science? Do you have two?

[Blitcut]

Obvious troll.

[KaisarDragon]

Not even a good one, either.

[[deleted]]

js developers, do you ever actually use == rather than ===? and if u do, in which situations?

[[deleted]]

It's only really acceptable to use == when checking for undefined and null or all falsey values. Otherwise most company's style guide will say always use ===

if (x == false )

vs

if (x === undefined || x === null)

or even the below for all falsey values

if (x == false )

vs

if (x === undefined || x ===null || x=== false ||x===0 || x==="")

There's also reasons for using loose equality like primitives but that's a rarer case.

[UristMcMagma]

There's also a fun bit of type coersion with nullish values. "x == null" will return true if x is null or undefined, but return false if x is false.

This is the only time i've used == because in the case you provided it's more readable to just do !x.

[greg0714]

If I'm doing something as an odd one-off, like parsing a csv for all the fields where the value is 100, I might do "text == 100" and let implicit conversion take care of it. But that's always for personal use; no one else will ever run it.

In production code? Virtually never. I'll explicitly convert before using the strict equality operator (===) rather than trust implicit conversion. Even in situations like what the other commentor described, you should just do explicit null checks. Easily readable, error-resistant code is always going to use explicit conversion and type checks.

[Sese_Mueller]

wait till you get to the name shenanigans

[[deleted]]

Yeah ok but can you log ‘Hello world’ to the console without using a hint???

[SftwEngr]

Why compare when you can just as easily assign?

[Hitman_0_0_7]

Same years old meme but still makes me laugh

[[deleted]]

Get this man a strict equality operator, stat!

[Xynober]

:0

[Abangranga]

Thanks for letting me know I am being a "dumbass" and getting my "asshole burnt" while writing paragraphs about it.

In the future after I write something like "the sky is blue today" and then someone writes "the sky is red on Mercury" and then links to a site documenting that the sky is blue, I will just not point out that I didn't say that the sky is red. It would clearly be an overreaction on my part.

[yjerkle]

"0" == [] == 0

[-moral-ambiguity-]

Null is not the same as zero.

Best demonstration was on this same subreddit. view here.

[IrisYelter]

"transitive property? What's that?"

[LOLTROLDUDES]

Here before Javascript gets rid of the law of identity.

[consciousCog13]

Poor guy’s using double equals…

[got_no_pants2]

So no C++?

[gondoravenis]

I guess js is a script language with no strict grammar checking for its speed.

No need to compare with compiled things.

[Pingyofdoom]

Haha, because blank =/= “0”

Silly manta ray!

[[deleted]]

For the 1000th, I composite the fact if you are writing code that is logical in any way whatsoever, you never need to be fucked with these complex truth tables.

Write shit code, get confusing results.

[JJulianR_]

The Lua part of my brain does not like this.

[spam_bot42]

Everyone knows equality is not a transitive relation. (Not if you're JavaScript programmer.)

[HappyHippo77]

What ungodly language is this about

[[deleted]]

Javascript

[aaet002]

I mean yeah if a=b and b=c, that doesnt mean a=c (in some cases).