4 ms·

I see a lot of comments here suggesting that == is okay to use if you know what you're doing or if the types on both sides match or if this or if that. Writing

• always_good 8y ago
  Agreed. The second you use `==`, now everyone else who encounters it has to do their own research to see if you indeed meant it. It's like every time you defensively throw in a nil-guard just in case: everyone now has to go "wait, can nils really get this far into the system?" You just start wasting the time of the people experienced enough to identify it as a potential problem.
  • SeriousM 8y ago
    Thank you, that was a well written summary of my thoughts.
• tenaciousDaniel 8y ago
  yeah if I'm doing any kind of loose type-checking I make it explicit. if (myNum === 2 || myNum === '2') {} It's very easy for developers to mistakenly "see" the third equality symbol and get confused by the intent of the code.
  • kenbellows 8y ago
    In that sort of case I like to use explicit type casting, e.g. if (Number(myNum) === 2) {} For me this also extends to using `Boolean(val)` instead of `!!val`, etc.; though I understand the appeal of those nifty one-liners, I think they cause confusion in many places and don't communicate intent nearly as well.
• thatswrong0 8y ago
  I only ever use == to do “x == null”, to check if x is undefined or null, but not any other falsey value like 0.
  • platz 8y ago
    that is the only good and handy use of it, yes.
• alangpierce 8y ago
  Depending on your conventions for null/undefined (another annoying wart of JavaScript), I think it often makes sense to treat `== null` as a special allowed case. In the code I work in, `== null` is strongly encouraged (but not required) as the way of doing null checks, and all other uses of `==` are disallowed by lint. Just like our other patterns and conventions, it's something people pick up reasonably quickly as they're introduced to the code, nothing tricky, just a little pattern that acts as a concise replacement to the `?` operator from CoffeeScript. The alternatives are writing `x === null || x === undefined` everywhere (which might lead to people just picking one out of laziness, leading to bugs), doing things like `if (x)` (which we still do sometimes, but can lead to subtle falsy-related bugs if you're not careful), or to do careful bookkeeping of when variables might be null vs undefined. In my opinion, the null/undefined distinction is more cognitive overhead than the benefit it provides, so it's best to just check for both at the same time and never intentionally treat them as different. Given that mindset, I think the `== null` pattern is slightly unfortunate, but better than the alternatives.
  • novaleaf 8y ago
    exactly! `==null` and `!=null` are the only reasons I use it. For those not aware, you can specify a rule in [js/es/ts]lint to allow only these cases.
  • Rumudiez 8y ago
    My team checks for types, not for null. `const isString = myVar => typeof myVar !== 'string'` This is more reusable and more idiomatic in my opinion than null/undefined checks
    • styfle 8y ago
      This is especially useful if you are using TypeScript (or Flow I assume) because the type checker can give you an error at compile time. After performing the runtime check, TypeScript will know that null/undefined is not possible. See this example https://goo.gl/AyoC3T https://goo.gl/AyoC3T
    • jscissr 8y ago
• deleted 8y ago
  [deleted]