4 ms·

Sounds like a toolbox full of sharp implements. I guess if you're really performance tuning these would be useful?

• brundolf 5y ago
  The thing is that most of these are severe anti-practices that you probably aren't doing anyway. Of course, I would still feel pretty nervous turning these on in a large multi-dev codebase unless some corresponding linter rules were also in place.
  • masklinn 5y ago
    > The thing is that most of these are severe anti-practices that you probably aren't doing anyway. Except when you’re doing them by mistake, or because a dependency happened to be clever and you missed it. See also: UB in every C and C++ code base.
    • brundolf 5y ago
      In theory dependencies shouldn't matter, because normally only your own code goes through Babel; library code has typically already been transformed into least-common-denominator JavaScript Most of these are pretty hard to do by accident... I didn't even know about maybe a third of these things, and I've been writing JavaScript for 10 years A significant exception to all of the generalizations I've been making is iterableIsArray: > When using an iterable object (in array destructuring, for-of or spreads), assume that it is an array. Violating this one is neither an anti-pattern nor hard to do by accident. It would mean a significant shift in practices for a project, and it would have to allow for some really exceptional optimizations if I were going to even consider enabling it
    • throwaway8581 5y ago
      Undefined behavior is overhyped. Most undefined behavior is perfectly defined and supported on the particular platforms being developed for. The official C specification is not a platform.