Refactor single argument functions #22
Comments
|
If you want to refactor a simple case of As for the exceptions you've provided I think we need to agree on a doc style we will use and only then touch such cases. Imo it will be better if we just describe everything before the function (something like jsdoc/javadoc/cpp-doc etc) so that the text won't clutter the actual parameters/implementation of the function and will further allow to also write them via simple (val1, val2, val3) =>
some-complex-but-one-line-checkCurrently, my concerns are:
Also, @JuliaGerasymenko please don't refactor |
Remove `requireForBlockBody` option of `arrow-body-style` rule.
BREAKING CHANGE: previously, only arrow functions consisting of a single
expression were allowed to omit parentheses around the parameter list
(and required to, if there's only one parameter in the list). After
this change, the parens are only allowed when they are required
syntactically.
Before:
```js
const f = x => x;
const g = (x, y) => x + y;
const h = (x) => {
console.log(x);
};
const i = (x, f) => {
f(x);
};
```
After:
```js
// Not affected
const f = x => x;
// Not affected
const g = (x, y) => x + y;
// AFFECTED
const h = x => {
console.log(x);
};
// Not affected
const i = (x, f) => {
f(x);
};
```
This rule is fixable via `eslint --fix`.
Refs: metarhia/Metarhia#22
Remove `requireForBlockBody` option of `arrow-parens` rule.
BREAKING CHANGE: previously, only arrow functions consisting of a single
expression were allowed to omit parentheses around the parameter list
(and required to, if there's only one parameter in the list). After
this change, the parens are only allowed when they are required
syntactically.
Before:
```js
const f = x => x;
const g = (x, y) => x + y;
const h = (x) => {
console.log(x);
};
const i = (x, f) => {
f(x);
};
```
After:
```js
// Not affected
const f = x => x;
// Not affected
const g = (x, y) => x + y;
// AFFECTED
const h = x => {
console.log(x);
};
// Not affected
const i = (x, f) => {
f(x);
};
```
This rule is fixable via `eslint --fix`.
Refs: metarhia/Metarhia#22
|
@JuliaGerasymenko once metarhia/eslint-config-metarhia#11 lands and the new version of ESLint config is published, the path forward is:
|
|
I don't like jsdoc style, it makes sources heavy-looking. I'd prefer to minimize comments at all. But if function arguments in not obvious I'd prefer to use simple |
Remove `requireForBlockBody` option of `arrow-parens` rule.
BREAKING CHANGE: previously, only arrow functions consisting of a single
expression were allowed to omit parentheses around the parameter list
(and required to, if there's only one parameter in the list). After
this change, the parens are only allowed when they are required
syntactically.
Before:
```js
const f = x => x;
const g = (x, y) => x + y;
const h = (x) => {
console.log(x);
};
const i = (x, f) => {
f(x);
};
```
After:
```js
// Not affected
const f = x => x;
// Not affected
const g = (x, y) => x + y;
// AFFECTED
const h = x => {
console.log(x);
};
// Not affected
const i = (x, f) => {
f(x);
};
```
This rule is fixable via `eslint --fix`.
Refs: metarhia/Metarhia#22
|
Done |
|
@tshemsedinov it's not done, though. I've just landed a PR by @belochub in JSTP (metarhia/jstp#371), but other repos haven't been refactored/ |
We have different code style for single argument functions in Metarhia modules.
Sometimes we use
(par) => parin other placespar => par. I propose to usepar => parin most places except special cases described below.So I propose to refactor core modules: common, jstp, metasync, metaschema, globalstorage, sandboxed-fs, impress, impress-cli, metatests, metacom, concolor, metalog, tickplate, do. @JuliaGerasymenko can do this when she have a free time from front-end tasks.
Exceptions:
/cc @aqrln @lundibundi @nechaido @belochub @alinkedd
The text was updated successfully, but these errors were encountered: