Refactor single argument functions

[tshemsedinov]

We have different code style for single argument functions in Metarhia modules.
Sometimes we use (par) => par in other places par => par. I propose to use par => par in 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:

const functionWithDescription = (
  // In single-argument functions with large description
  par // string, meaning of par argument
  // Returns: string, meaning of result value
) => {
  // implementation
};

/cc @aqrln @lundibundi @nechaido @belochub @alinkedd

[lundibundi]

If you want to refactor a simple case of (val) => res to val => res then I think one eslint --fix run with a proper rule can do that.

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 val => res or

(val1, val2, val3) => 
  some-complex-but-one-line-check

Currently, my concerns are:

• We have long comments to describe the parameters, behavior (i.e https://github.com/metarhia/jstp/blob/master/lib/server.js#L60, https://github.com/metarhia/jstp/blob/master/lib/common.js#L118 etc) which is not feasible with the style in the post above as this will clutter it too much that it will be hard to distinguish comment and parameters
• There is even less space for comments this way and this makes them stretch down even more (in order to have it neatly and 'readably' aligned)
• Any decent editor is able to print 'comment-above-function' for you as a function doc, whatever it is. But if we use some specific style it will make that impossible
• When you change comments with the style above you may have to reorder the parameters and or change style that cause unnecessary diff clutter
• It makes impossible to add comments to a one-line (2-line) simple functions as you have to split it to add a comment in-between and it will no longer be a one-liner

Also, @JuliaGerasymenko please don't refactor metatests until metarhia/metatests#66 has landed.

[aqrln]

@JuliaGerasymenko once metarhia/eslint-config-metarhia#11 lands and the new version of ESLint config is published, the path forward is:

1. Checkout each repo throughout the org for which you have write access. For those you don't, fork them and then checkout your fork.

2. Even when you fork a repo, always switch to a new branch anyway.

3. You will be modifying package-lock.json (albeit indirectly), so make sure to use the latest npm version. If npm -v prints anything less than "6.4.0", update Node.js and run npm i -g npm@latest.

4. Update eslint-config-metarhia to ^4.0.0 if it is present in devDependencies. If it's not, it should be, so add it instead, and replace the outdated .eslintrc.yml with .eslintrc (or .eslintrc.json, which is the same) with the following content:

   {
     "extends": "metarhia"
   }

   If npm complains about missing peer dependencies, then you also have to update (or install) eslint and eslint-plugin-import.

5. Run npm run lint -- --fix or whatever the npm script in a particular package is (it's probably lint in all of them though). If any errors remain, fixup them manually.

6. Commit all of those changes and submit a PR.

[tshemsedinov]

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 // before function or comment style I suggested above. We have a special parser for this style, @lundibundi

[tshemsedinov]

Done

[aqrln]

@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/eslint --fix'ed by anyone yet.