* How to Deploy Functions in this Software Framework * - ALWAYS use arrow function expressions (AFEs), UNLESS there is a specific need to refer to a function as `this` from within its own body ... and to a less significant degree, if you need the function's `arguments` array. Heuristics: prefer terseness; explicitly state intentions. - ALWAYS use async functions, UNLESS there is a specific advantage to force synchronous responses. Heuristic: prefer decoupling. - Use generator functions ONLY when there is a specific need for such functionality. (Note added for completeness. Did we miss any other type of function?) * How to Deploy Promises in this Software Framework * - ALWAYS use the following taxonomy: ( Promise ( ( fulfillFn, rejectFn ) => {} // an `executor` ).then( onFulfilled ( value ) => {}, // a Promise is `settled`1 onRejected ( reason ) => {} // a Promise is `settled`2 ).catch( // sugared .then() onRejected ( reason ) => {} ).finally( regardless () => {} // No argument is ever passed. ) ) - Do NOT use: `resolve` in place of `fulfill` `resolved` in place of `settled` `result` in place of `value` `error` in place of `reason` Heuristic: prefer standards (the etymology is complex; I have a slide). - ALWAYS enter both arguments of Executors, and .then(), EVEN IF one argument will not be used. For minimal line noise, consider using `_`, `f`, `r`, `onF`, `onR`. Heuristic: terseness; explicitly deny options. - ALWAYS use `await`, and therefore `try { await } catch (e) { handler }` UNLESS some of the above is more succinct. Heuristics: terseness; explicitly state intentions.
2020-05-12 at 10:06 pm
Hard Choices and Censorship (in JavaScript)
I think I'm ready to lay down some rules, a sort of style guide, for this framework I'm writing for Node-on-Lambda.
Subscribe to:
Post Comments
(
Atom
)
No comments :
Post a Comment