Hacker News Reader

Comment by pdpi | Hacker News Reader

Oh that is nasty.

For anybody who cares: `a == c` coerces `a` into a number . `a` is a hexadecimal string that happens to have only one non-numeric 'digit', and that digit happens to be an 'e'. This triggers parsing as scientific notation. For both `a` and `b`, the only digit in the significand is 0, so the result is 0.

View on HN

Roughly 7 years ago, I started using strict equality comparisons (===) in PHP and JS to avoid issues like this, and doing so has had zero negative impact on my code and obviously a MUCH higher upside. Is there any reason for using sameness (==) merely beyond convenience?

I can't even remember the last time I worked in a Javascript project where you could find "==" in the codebase. It even got phased out as a convenient "null or undefined" check.

Between it being an ancient footgun and the ubiquity of linters, making fun of "==" code ends up just making fun of beginners.

Thank goodness for nullish coalescing.

I still use it for null/undefined checks, because it’s almost always what’s intended/expected. I was surprised to find out recently that this is even a remotely controversial take.

I do try to use the newer language features like nullish-coalescing and optional chaining to make the check less necessary, but sometimes it makes more sense (clearer code, less unnecessary code execution) to check for null/undefined and return early.

Even with a linter that can approve of that one use case, the problem with == these days is that it catches everyone off guard, and every developer who sees the code has to do the same "did they mean to use this or-- oh, it's for a null|undefined check" every single time.

Just because of that I've created an `isNil = (x) => x is undefined or null` function and banished == from my code.

== can lead to what we've jokingly called tollbooth code: code that can make every reader stop and pay a mental toll while they confirm that the writer did intend to write the code that way.

This is surprising to me! I/my team do use such a linter rule (non-strict equals errors for all cases except directly comparing to null), and I don’t even notice it while reading code because the linter is satisfied, and because it reads as (obviously, to me) correct.

It never occurred to me that it could be so noticeable to others as to add any cognitive overhead. I’m not discounting that at all, to be clear, only that it’s not something I’d ever considered before now.

We have banished it as well for this exact reason — the “toll” — if you want 1 more piece of anecdata.

I think it's a lot less nasty than the Python version. At least the JS version only gives you a weird answer if you're comparing a number to a string, while Python will automatically do a weird type conversion even if you're just comparing two "number looking strings" to begin with.

Edit: I'm an idiot, thanks for the responses for correcting me, was thinking PHP but had Python on the brain I guess. Original bad edit: I was downvoted pretty hard, but I think I was just unclear. In Python, doing md5("foo") == md5("bar") returns true because Python converts both strings to numbers first because they have an e in them. That is, in my opinion, Python is doing an unnecessary conversion there that JS doesn't do in that case. See https://stackoverflow.com/questions/12598407/why-does-php-co...

Python doesn’t do any automatic type conversion for strings

That's false, and that's the point I was trying to make, albeit unclearly - see https://stackoverflow.com/questions/12598407/why-does-php-co...

That's about PHP

... no? Python's == never does implicit type conversions unless one of the types overrides it to do so (neither str nor int does)

There's one small gotcha with Python.

  >>> 1 == True
  True

Yes, but not because of type conversion: Python's booleans are a subclass of int.

I think you keep writing "Python" when you intended to write "PHP".

Lol, thanks, I'm an idiot, it was the brain fart that kept going.

Reply on news.ycombinator.com