3 ms·
One of the biggest warts is the difference between the == and === operators. Eich attempted to alter the behavior of == in order to fix it, but was not allowed
by kokanee 3y ago
One of the biggest warts is the difference between the == and === operators. Eich attempted to alter the behavior of == in order to fix it, but was not allowed to ship the change for fear of backwards incompatibility, forcing him to add a new operator instead. To this day, recommended linter settings disallow use of the == operator entirely.
- deleted 3y ago[deleted]
- jancsika 3y agoCould "use strict;" have silently changed all occurrences of "==" to "==="?
- wk_end 3y ago`==` and `!=` are still quite handy when you don't want to deal with the distinction between `null` and `undefined`, which is almost always what you want.
- kokanee 3y agoIf you do this, you need to think through all the possible types for the comparators and how type coercion will affect the expression. For example, `0 == ''`, `[] == ''`, and `[] != []` are all `true`. If you're using typescript to get guarantees about the input types, maybe that's a good use case for using type coercion intentionally.
- nerdwaller 3y agoI find that I really appreciate the explicit rather than the implicit comparisons (requiring `===` in js), especially picking up a new program or coming back to one after some time away. I view it like a database - do I really want multiple ways to show a value is empty? For something like a Boolean you have: `false`, `true` and `null` as valid values (trilean?) that now have to be handled.
- Vinnl 3y agoActually, I was surprised to learn last week that the `eqeqeq` rule that disallows `==` is not in ESLint's recommended set: https://eslint.org/docs/latest/rules/ https://eslint.org/docs/latest/rules/ (And I immediately enabled it for our codebase. Generally I like to just rely on the recommended non-stylistic rules, but this is such an easy footgun that everybody on my team already defaulted to adhering to, that I made an exception.)