The beauty of (coding) standards is that there are so many to choose from. :)
IMO it’s a false dichotomy though. A respected and credible group of language contributors should pool some energy together and ratify some opinionated best practices, a la the C++ Core Guidelines and PEP-8. No, it’s not *necessary*—neither is the exponent operator—but it does have clear benefits. I believe most in the community would rather not have to sell things like “const by default” to their team members, when it could be “official” guidance instead. It’s energy we’d rather be spending on other things! Alex On Wed, 18 Oct 2017 at 06:59, Jordan Harband <ljh...@gmail.com> wrote: > These questions have consumed programmers in most languages since forever. > It's not TC39's place to tell people how to write code - but there's plenty > of style guides that have answers to these questions. > > On Tue, Oct 17, 2017 at 10:44 PM, kai zhu <kaizhu...@gmail.com> wrote: > >> there are several factors for the current javascript-fatigue. one factor >> which tc39 could help mitigate is to provide a narrative on how to >> consistently apply proposed language-features (over existing-practices and >> interfacing with legacy-code). >> >> i feel too many new and old javascript-programmers alike are unable to >> adopt a consistent programming-style for post-es5 features in >> production-code. style-issues which are problematic when a project has to >> deal with legacy libraries include: >> >> - when is it appropriate to use callback vs promise vs async-generator vs >> async/await, when interfacing with legacy-code (aka context-switching-hell >> or baton-passing-hell)? >> - when is it appropriate to use var vs let, when interfacing with >> legacy-code? >> - when is it appropriate to use function vs fat-arrow, when interfacing >> with legacy-code? >> - how can we apply destructuring in a consistent and readable manner? >> - when is it appropriate to use (proposed) pipeline-operator, and when is >> it not? >> >> es6/es7/es8 introduces hundreds of these kinds of questions which >> distract us from actual coding and shipping features. >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
