3 ms·

Prettier oftentimes removes a lot of parentheses that I had hoped it would leave. I’ve taken naming them as variables instead. Definitely more verbose but more

• deleted 3y ago
  [deleted]
• pests 3y ago
  That is how it evaluates, not what the original author intended in the example in the OP. return a === b ?? c; The intent was const bOrDefault = b ?? c; return a === bOrDefault; You posted the actual (buggy) evaluation. I agree that its better if that is what you intend.
• pests 3y ago
  Wait, your example doesn't even make sense to me on second thought (and was the ultimate point in the article) aIsB is guaranteed to not be null or undefined so the ?? is a no-op. You just did a comparison so it's either true or false. For general clarify for precedence I still agree but in this case it's a silly thing to do. It would be more clear without the syntax shorthand: const ret = a === b if(ret == null || ret == undefined) { ret = c } return ret
  • SenHeng 3y ago
    I was referring particularly to my parent's point about adding parentheses to remove ambiguity. That prettier oftentimes removes parentheses that I explicitly want. So rather than risk that, I remove the ambiguity by moving one of the comparisons off into a named variable.
    • pests 3y ago
      I agree. I was just pointing out that this is a case prettier wouldn't do anything. The expression parses differently and adding or removing parentheses to any subexpression will change its meaning. That by manually doing the transform in your example that you would realize your cody was a no-op or that the intended version was what I posted.