Though, PEP-8 was created in 2001 and in significant part codified already used conventions. And JavaScript does not have such widely followed conventions - except camelCase for functions and PascalCase for classes.
On Fri, Oct 20, 2017 at 10:19 AM, Alexander Jones <[email protected]> wrote: > I used the term 'language contributors' rather than TC39 as an > intentionally vague way of describing people like us. > > 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. > > 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. > > 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. ;) ) > > On 20 October 2017 at 00:54, Isiah Meadows <[email protected]> wrote: > >> In general, it's not the TC39 who should be dictating how code is >> written - in particular, even they have their stylistic disagreements >> (like with ASI and `let` vs `const`), and active TC39 representative >> maintain both JSHint (opinionated) and ESLint (unopinionated). >> Additionally, JSLint (the predecessor to JSHint) was created by a >> formerly active TC39 representative. If you want to see more of these >> broad stylistic disagreements, check out [their meeting notes][1]. A >> few things that come to mind are decorators, cancellation, recent >> class additions, and [BigInt][2]. >> >> Instead, if you have your own strong opinions on everything, try >> introducing [ESLint][3] to your projects. They have numerous presets >> and rules built-in, and you can create your own custom presets, rules, >> and plugins. If you want to ban `null`, write a custom rule for it. If >> you want to ban anything not ES5, write a rule that catches every >> expression that isn't ES5. If you want to define local rules, use >> [eslint-plugin-local][4]. In my case, I decided I didn't want to use >> default exports, so I wrote a local rule banning all default exports. >> Not that I have a problem with those who use it - I don't. I just feel >> it's easier for me to wrap my head around named exports without >> introducing the cognitive overhead of default exports. >> >> [1]: https://esdiscuss.org/notes >> [2]: https://esdiscuss.org/notes/2017-01-25#15iv-progress-report- >> and-request-for-comments-on-64-bit-int-support >> [3]: https://eslint.org/ >> [4]: https://github.com/taskworld/eslint-plugin-local >> ----- >> >> Isiah Meadows >> [email protected] >> >> Looking for web consulting? Or a new website? >> Send me an email and we can get started. >> www.isiahmeadows.com >> >> >> On Wed, Oct 18, 2017 at 6:37 AM, Naveen Chawla <[email protected]> >> wrote: >> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 >> >>>> [email protected] >> >>>> https://mail.mozilla.org/listinfo/es-discuss >> >>> >> >>> >> >>> _______________________________________________ >> >>> es-discuss mailing list >> >>> [email protected] >> >>> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> _______________________________________________ >> >> es-discuss mailing list >> >> [email protected] >> >> https://mail.mozilla.org/listinfo/es-discuss >> > >> > >> > _______________________________________________ >> > es-discuss mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> > >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
