I disagree that the language contributors should be involved in best practice guidance. Patterns evolve over usage and experience with the constructs. I bet the implementors of `&&` and `||` didn't necessarily expect them to be used so effectively for non-boolean logic e.g. `car && car.drive()` instead of `if(car!==undefined) car.drive()` or whatever... Or maybe they did. But the point is language usage is often a matter of opinion and preference, and not something that should be set as a tide against a possibly justifiable opposition. As a response to the original question, I gave my opinion and reason in brackets. If the reader prefers a different way for their own reasons, fine - I would just expect them to give their own reasons for superseding my reasons...
On Wed, 18 Oct 2017 at 14:34 Alexander Jones <a...@weej.com> wrote: > 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 >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
