styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

Michał Wadas michalwadas at gmail.com
Fri Oct 20 09:16:36 UTC 2017


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 <alex at weej.com> 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 <isiahmeadows at gmail.com> 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
>> me at isiahmeadows.com
>>
>> 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 <naveen.chwl at gmail.com>
>> 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 <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!
>> >>
>> >> Alex
>> >>
>> >> 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:
>> >>>>
>> >>>> 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 at mozilla.org
>> >>>> https://mail.mozilla.org/listinfo/es-discuss
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> es-discuss mailing list
>> >>> es-discuss at mozilla.org
>> >>> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> es-discuss at mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171020/ae730754/attachment.html>


More information about the es-discuss mailing list