Hacker News Reader

Comment by nielsbot | Hacker News Reader

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

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.

> 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.

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

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.

Reply on news.ycombinator.com