13 ms·
It's so funny. Anybody still using == with js?
by ttty 8y ago
It's so funny. Anybody still using == with js?
- simias 8y agoPlenty of beginners I'm sure. People who come from languages where == is not broken will probably default to using it, if only because of muscle memory. It might not be immediately obvious that it's broken too which makes it worse.
- CraneWorm 8y agoPeople relying on its broken behaviour :)
- DougBTX 8y agoI'm interested to know what people think about this with TypeScript - quite a lot of the weird behaviour in plain JS is rejected by the compiler, eg, "true == 1" evaluates to true in plain JS, but is a compiler error in TypeScript since it rejects bool vs number equality checks. So with TypeScript code, I've been continuing to use == as in most other languages, with the expectation that any odd comparisons will be flagged by the compiler. On the other hand, I've not verified myself that it catches them all, so I wonder if anyone has come across other edge cases with this that could cause problems down the line.
- slikts 8y agoThe issue there is that TS allows dropping out of the type system with `any`, so it might not actually be checking the types you're comparing, so I'd still use ===.
- kbp 8y agoI prefer it when Typescript tries to provide static type checking for Javascript rather than providing checking for how they wish Javascript was. `(x: number, y: string) => x == y` is an error because 'this condition will always return false'. In what language? There are linter rules for enforcing === over ==; Typescript having incorrect type definitions to try and make sure you only use == like === seems like a really poor solution to that.
- Sacho 8y agoAren't you implicitly assuming that TS's number === JS's Number and TS's string === JS's String? You could say == is extended for TS's types(number/string), but the JS == still exists: x as any == y as any;
- kbp 8y agoI can see what you're saying, but I think that argument would be a lot stronger if == compiled to ===. If you want an operator with ==='s semantics, it's there; providing == and claiming it behaves like === just seems like an opportunity for annoying surprises if something slips through the cracks. Since == doesn't compile to ===, I wouldn't use it unless I understood its semantics and wanted them.
- arisb 8y agoI'm guessing you can't use `(x: number, y: string) => x === parseInt(y)`?
- jaaames 8y agoAs long as you feed parseInt it's second radix parameter you can :p
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- slikts 8y agoIt's idiomatic to use == to check for both null and undefined at least. A lot of people seem to have a perception of languages as being handed down by some language gods, and apparent problems with the language get explained away by "mere users" lacking knowledge, perspective, discipline, etc.
- skrebbel 8y agoEverybody who uses >= and <= implicitly uses ==. That said, if you mix types between comparison operands or inside arrays then you probably have bigger problems than "==" semantics. :-)
- paradite 8y agoPeople who writes `if(value)`
- blauditore 8y agoBut that's not the same; it's about truthy-ness. E.g. -1 and 1 are both truthy, but not loosely equal.
- paradite 8y agoYou are right. I confused truthy-ness with '== true' for some reason, didn't write much JS lately.
- paulintrognon 8y agoThat's weird, I would thought that if(value) was the equivalent of if(value == true). Learned something today!
- pythonaut_16 8y agoYou can force cast a boolean by doing if(!!value == true) {}, but at that point you might as well just say if(value)
- darepublic 8y agoTruthy ? A : B Truthy && A Falsy || fallback
- 11235813213455 8y agoFor typeof obj == '..' you don't need === since typeof always returns a string And the engine makes it as fast as === https://github.com/dperini/nwsapi/pull/11#issuecomment-383275455 https://github.com/dperini/nwsapi/pull/11#issuecomment-38327... (Generally else == is slower than ===)
- deleted 8y ago[deleted]
- atirip 8y agoYes. In our codebase it is forbidden to test for true/false, only truthy/falsy is allowed. The only place where === is needed and allowed is testing for if function argument is omitted. Otherwise == and yes, all developers understand that and agree and no, we haven’t had any bugs because of that. Big and complex web app, not my first, the previous gig was even bigger, same approach. Works like a charm.
- deleted 8y ago[deleted]
- noxToken 8y agoBut why? I'm having a hard time understanding why you'd outright ban identity (===) and only allow equality (==). I can think of one instance where I needed identity instead of equality, and I took the time to refactor to ensure that equality would work.
- atirip 8y agoWe fully embrace Javascript as dynamically typed language and when one does this, types on most cases will become irrelevant. Then also using === in the code means that the usage is explicitly required in this specific place and == will cause wrong result. But when === and == are the same, then we use strictly ==. Also read this: http://dmitry.baranovskiy.com/post/typeof-and-friends http://dmitry.baranovskiy.com/post/typeof-and-friends If you are curious, please post some real life real working code where in your mind usage of === is absolutely needed and I try my best to explain how I would tackle that with ==.
- simias 8y ago>We fully embrace Javascript as dynamically typed language [...] I won't outright dismiss your coding style because I don't know what your codebase looks like and maybe you're genuinely talented JS devs who know what they're doing (something I'm decidedly not) but your comment makes it sound like discouraging the use of '==' is not "embracing" JS's dynamism. I don't think I agree with that, actually there are a bunch of highly dynamic languages where comparison is not such a mess. The main problem with '==' is that it's highly inconsistent and intransitive (as showcased by TFA). It's tricky to figure out what evaluates to true or false when types don't match. It's not PHP bad but it's pretty damn bad.
- christophilus 8y agoWe use it to check if a value is null or undefined (`foo == null`) is true for both `foo = null` and `foo = undefined`, which is pretty handy. Other than that, we don't use `==`.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- marijn 8y agoAs long as the types on both sides match, the behavior of == is perfectly reasonable, and in typical uses, this will be the case.
- mishoo 8y agoI do, when I know the types match. Also, I always use == to test if something is either null or undefined; cases where the distinction matters are extremely rare, and this looks too silly: typeof foo === "undefined" || foo === null.
- deleted 8y ago[deleted]
- yoklov 8y agoFirefox has a few million lines of JS code and the coding standard prefers `==` to `===`. I don't think it's linted for though.