None of this is new and I don’t know that it’s possible to follow these 100%. But if these are your targets then your code will be a pleasure to work with.

The Function Does Not Rely on Hidden Cleverness

Language peculiarities around order of interpretation for type coercion are confusing. Yes it’s fun to explore them, but leveraging them in production is effectively setting a landmine for the next developer who touches that code.

The Function Makes Sense in Isolation

The reasons why a function was constructed are apparent from the title and contents of the function, without the need for additional context of the caller or any internally called functions.

If a developer needs to read anything other than the function to understand what it’s doing, it’s not readable. The ultimate first prize is to convey precise meaning with the function name alone.

The Function Assumes Knowledge of the Language

Yes the semantics of Promises and methods like .reduce are cumbersome. Yes closure and context take effort to initially get your head around. Yes you still need to be comfortable with all of that.

The one caveat here is to be careful not to fall into leveraging hidden cleverness.

Consistency Trumps Comfort

So much of bug reduction boils down to eliminating surprises. If you join a front end team of ex-backend devs who are all writing functions like this:

function makeThingsHappen()
{
  // things happening
}

or they’re using / not using semicolons, or they’re using spaces / tabs, or [insert your pet peeve here], just bite the bullet and join in. Get some auto-formatting and let go of your petty preferences, they truly do not matter. Your ability to become comfortable in environments that go against your personal preferences is a professional quality — develop it.