naveen.chwl at gmail.com
Wed Oct 18 10:37:13 UTC 2017
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 <alex at 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!
> On Wed, 18 Oct 2017 at 06:59, Jordan Harband <ljharb at 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 <kaizhu256 at gmail.com> wrote:
>>> 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).
>>> 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
>>> - 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 at mozilla.org
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss