<div dir="ltr">I used the term 'language contributors' rather than TC39 as an intentionally vague way of describing people like us.<div><br></div><div>The ISO C++ Committee also lacks a consensus on everything, but that doesn't mean those people and the people around them can't debate and establish a consensus on *something*. Hence, C++ Core Guidelines.</div><div><br></div><div>I think the reality is that people are averse to this because they don't want their pet practices at work being discouraged by anything resembling official guidance — having to justify a decision to use `var` instead of `const` by default is *effort*, right? But they're perhaps not always considering the benefits that an improvement in (not necessarily total) uniformity can bring.</div><div><br></div><div>I claim that the majority in the Python community would say that PEP-8 has been a net benefit. (Yes I break its rules from time to time. That's what rules are for. ;) )</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 October 2017 at 00:54, Isiah Meadows <span dir="ltr"><<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In general, it's not the TC39 who should be dictating how code is<br>
written - in particular, even they have their stylistic disagreements<br>
(like with ASI and `let` vs `const`), and active TC39 representative<br>
maintain both JSHint (opinionated) and ESLint (unopinionated).<br>
Additionally, JSLint (the predecessor to JSHint) was created by a<br>
formerly active TC39 representative. If you want to see more of these<br>
broad stylistic disagreements, check out [their meeting notes][1]. A<br>
few things that come to mind are decorators, cancellation, recent<br>
class additions, and [BigInt][2].<br>
<br>
Instead, if you have your own strong opinions on everything, try<br>
introducing [ESLint][3] to your projects. They have numerous presets<br>
and rules built-in, and you can create your own custom presets, rules,<br>
and plugins. If you want to ban `null`, write a custom rule for it. If<br>
you want to ban anything not ES5, write a rule that catches every<br>
expression that isn't ES5. If you want to define local rules, use<br>
[eslint-plugin-local][4]. In my case, I decided I didn't want to use<br>
default exports, so I wrote a local rule banning all default exports.<br>
Not that I have a problem with those who use it - I don't. I just feel<br>
it's easier for me to wrap my head around named exports without<br>
introducing the cognitive overhead of default exports.<br>
<br>
[1]: <a href="https://esdiscuss.org/notes" rel="noreferrer" target="_blank">https://esdiscuss.org/notes</a><br>
[2]: <a href="https://esdiscuss.org/notes/2017-01-25#15iv-progress-report-and-request-for-comments-on-64-bit-int-support" rel="noreferrer" target="_blank">https://esdiscuss.org/notes/<wbr>2017-01-25#15iv-progress-<wbr>report-and-request-for-<wbr>comments-on-64-bit-int-support</a><br>
[3]: <a href="https://eslint.org/" rel="noreferrer" target="_blank">https://eslint.org/</a><br>
[4]: <a href="https://github.com/taskworld/eslint-plugin-local" rel="noreferrer" target="_blank">https://github.com/taskworld/<wbr>eslint-plugin-local</a><br>
-----<br>
<br>
Isiah Meadows<br>
<a href="mailto:me@isiahmeadows.com">me@isiahmeadows.com</a><br>
<br>
Looking for web consulting? Or a new website?<br>
Send me an email and we can get started.<br>
<a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, Oct 18, 2017 at 6:37 AM, Naveen Chawla <<a href="mailto:naveen.chwl@gmail.com">naveen.chwl@gmail.com</a>> wrote:<br>
> I disagree that the language contributors should be involved in best<br>
> practice guidance. Patterns evolve over usage and experience with the<br>
> constructs. I bet the implementors of `&&` and `||` didn't necessarily<br>
> expect them to be used so effectively for non-boolean logic e.g. `car &&<br>
> car.drive()` instead of `if(car!==undefined) car.drive()` or whatever... Or<br>
> maybe they did. But the point is language usage is often a matter of opinion<br>
> and preference, and not something that should be set as a tide against a<br>
> possibly justifiable opposition. As a response to the original question, I<br>
> gave my opinion and reason in brackets. If the reader prefers a different<br>
> way for their own reasons, fine - I would just expect them to give their own<br>
> reasons for superseding my reasons...<br>
><br>
> On Wed, 18 Oct 2017 at 14:34 Alexander Jones <<a href="mailto:alex@weej.com">alex@weej.com</a>> wrote:<br>
>><br>
>> The beauty of (coding) standards is that there are so many to choose from.<br>
>> :)<br>
>><br>
>> IMO it’s a false dichotomy though. A respected and credible group of<br>
>> language contributors should pool some energy together and ratify some<br>
>> opinionated best practices, a la the C++ Core Guidelines and PEP-8. No, it’s<br>
>> not *necessary*—neither is the exponent operator—but it does have clear<br>
>> benefits.<br>
>><br>
>> I believe most in the community would rather not have to sell things like<br>
>> “const by default” to their team members, when it could be “official”<br>
>> guidance instead. It’s energy we’d rather be spending on other things!<br>
>><br>
>> Alex<br>
>><br>
>> On Wed, 18 Oct 2017 at 06:59, Jordan Harband <<a href="mailto:ljharb@gmail.com">ljharb@gmail.com</a>> wrote:<br>
>>><br>
>>> These questions have consumed programmers in most languages since<br>
>>> forever. It's not TC39's place to tell people how to write code - but<br>
>>> there's plenty of style guides that have answers to these questions.<br>
>>><br>
>>> On Tue, Oct 17, 2017 at 10:44 PM, kai zhu <<a href="mailto:kaizhu256@gmail.com">kaizhu256@gmail.com</a>> wrote:<br>
>>>><br>
>>>> there are several factors for the current javascript-fatigue.  one<br>
>>>> factor which tc39 could help mitigate is to provide a narrative on how to<br>
>>>> consistently apply proposed language-features (over existing-practices and<br>
>>>> interfacing with legacy-code).<br>
>>>><br>
>>>> i feel too many new and old javascript-programmers alike are unable to<br>
>>>> adopt a consistent programming-style for post-es5 features in<br>
>>>> production-code.  style-issues which are problematic when a project has to<br>
>>>> deal with legacy libraries include:<br>
>>>><br>
>>>> - when is it appropriate to use callback vs promise vs async-generator<br>
>>>> vs async/await, when interfacing with legacy-code (aka<br>
>>>> context-switching-hell or baton-passing-hell)?<br>
>>>> - when is it appropriate to use var vs let, when interfacing with<br>
>>>> legacy-code?<br>
>>>> - when is it appropriate to use function vs fat-arrow, when interfacing<br>
>>>> with legacy-code?<br>
>>>> - how can we apply destructuring in a consistent and readable manner?<br>
>>>> - when is it appropriate to use (proposed) pipeline-operator, and when<br>
>>>> is it not?<br>
>>>><br>
>>>> es6/es7/es8 introduces hundreds of these kinds of questions which<br>
>>>> distract us from actual coding and shipping features.<br>
>>>> ______________________________<wbr>_________________<br>
>>>> es-discuss mailing list<br>
>>>> <a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
>>>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
>>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> es-discuss mailing list<br>
>>> <a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
>>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> es-discuss mailing list<br>
>> <a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
><br>
</div></div></blockquote></div><br></div>