[ES6 Coding Style Discussion] Require parens for arrow function arguments?

[Fred Lin]

Recently we do use more ES6 in our source code, I think its time to discuss what coding style we want to follow with or what tools that we can leverage to automatic the linting.

The top most that bother me is whether we need (arrow parens).

I saw eslinter already support a ES6 lint rule for it

http://eslint.org/docs/rules/arrow-parens

The rule can be configured as `always`(default) or `as needed`.

The question is, which style is preferred for us?



FYR,

1. Google and Airbnb does not enforce ES6 style yet (might because they haven't heavily use it). Walmart use `always`(default) in their coding style settings.
https://github.com/walmartlabs/eslint-config-defaults/blob/master/rules/eslint/es6/walmart.js

2. Either

(param) => {}

or

param => {}

are correct ES6 syntax.

regards
--

Fred

[Patrick Brosset]

Not actually answering the question, but this might be of interest:

both the Hello team and the DevTools team have started using ESLint and you can find .eslintrc configuration files in tree (browser/devtools/.eslintrc and browser/components/loop/.eslintrc and others).

Looking at the way the various ESLint rules have been configured for these projects might be of interest to you.

Also note that recently, the './mach eslint' command landed, it's useful to run ESLint on any set of files. And Mike Ratcliffe of the devtools team is working on a './mach eslint-setup' command [1] that would install ESLint and the various Mozilla specific plugins that may be needed.\

Talking about which, we're in the process of creating specific rules [2] that help with validating Mozilla-style js code.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1203520

[2] https://github.com/mozilla/eslint-plugin-mozilla

_______________________________________________
dev-gaia mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

[Kevin Grandon]

My preference here for single argument functions would be to have no parens.

I actually have a linter for this here, and am happy for this to go into the mozilla plugins or gaia codebase:

https://github.com/KevinGrandon/eslint-plugins/blob/master/lib/rules/arrow-function-parens.js

(Also this should probably be moved to dev-fxos)

Best,

Kevin

[Julien Wajsberg]

In the SMS team, as a convention we adopted "always". But I don't really mind TBH.

About the tools, I had in my mind to set up jscs for codestyle and possibly move to eslint instead of jshint for static analysis.
Bug for JSCS is https://bugzilla.mozilla.org/show_bug.cgi?id=1194284

Le 16/09/2015 10:21, Fred Lin a écrit :

[Guillaume Marty]

The high level rule for coding style should always be how does this syntax helps to make the code more readable?

In this case, I think the parens add clutter to the code with no added benefits. The advantage of fat arrows over old-school functions is they're visually lighter, so I'd take all the possibility offered by the new syntax. In the case of one liner fat arrow functions (ex. `array.map(a => a.blah)`), the less code the better.

--

Guillaume Marty
@g_marty
http://gu.illau.me

[Eli Perelman]

On Wed, Sep 16, 2015 at 11:33 AM, Guillaume Marty <gma...@mozilla.com> wrote:

The high level rule for coding style should always be how does this syntax helps to make the code more readable?

In this case, I think the parens add clutter to the code with no added benefits.

I slightly disagree with this. The point of making the parens "always" is to reduce friction when needing to refactor the signature of a function. Whether moving from one argument to many, or many to one, you have to always change whether there would be parens or not if you didn't follow the "always" convention:

```

// Original:

array.map(value => log(value));

// Wanting to log index also requires adding parens:

array.map((value, index) => log(value, index));

// Whereas having parens always would only need argument changes:

array.map((value) => log(value));

```

Yes, I understand that the changing of parens and enforcement of style can be controlled through linters, and adding and removing of parens is trivial, but it's about simple conventions that reduce friction. In that case, I would argue that parens "always" is the way to go.

Eli Perelman

[Julien Wajsberg]

I just want to add that we adopted "always" quite arbitrary, without any argument. We just wanted to stick to a decision so that we don't need to nitpick all the time.
We thought both possibilities were good (each their advantages/inconvenients) so we just chose one.

BTW I think the rule should not necessarily be Gaia-wide, but more per-app and per-project (and a Gaia rule for /shared and things like that). All linters allow per-directory rules anyway.

[Guillaume Marty]

On 16 September 2015 at 17:45, Eli Perelman <eper...@mozilla.com> wrote:

On Wed, Sep 16, 2015 at 11:33 AM, Guillaume Marty <gma...@mozilla.com> wrote:

The high level rule for coding style should always be how does this syntax helps to make the code more readable?

In this case, I think the parens add clutter to the code with no added benefits.

I slightly disagree with this. The point of making the parens "always" is to reduce friction when needing to refactor the signature of a function. Whether moving from one argument to many, or many to one, you have to always change whether there would be parens or not if you didn't follow the "always" convention:

```

// Original:

array.map(value => log(value));

// Wanting to log index also requires adding parens:

array.map((value, index) => log(value, index));

// Whereas having parens always would only need argument changes:

array.map((value) => log(value));

```

I thought about this argument before, but frankly what's the number of times a particular piece of code is refactored vs. the number of times it's read by a fellow coder?

Also refactoring functions signature should really be handled by your IDE. WebStorms does it through a dedicated menu.

But as Julien suggested, allowing per app configuration seems to be the more flexible approach.

 

Yes, I understand that the changing of parens and enforcement of style can be controlled through linters, and adding and removing of parens is trivial, but it's about simple conventions that reduce friction. In that case, I would argue that parens "always" is the way to go.

Eli Perelman