Add code quality metrics to standard

[ghost]

It does not mention anything about:

• Variadic functions
• Function length
• Statement length
• Function cyclomatic complexity
• Statement cyclomatic complexity
• Redefining variables
• Setting values to function arguments
• Dealing with numbers: exact comparisons with floating point numbers, checking for NaN/Infinity
• Dealing with dates
• Dealing with booleans (e.g: name all booleans, use a prefix like "can", "has", "is")
• .... (all the things that make a standard practical).

In short, people can respect your standard and still produce code that is hard to maintain.
standard emphasizes whitespace but not true readability.

(Disclaimer: edited for better tone)

[jprichardson]

standard doesn't prevent people from writing horrible code as "horrible" is not an objective measure but a subjective one. standard sets a baseline, removes thought from silly decisions, and increases team cohesion. standard is a start, not the panacea.

Fortunately standard is extremely easy to extend; you can extend it with rules that satisfy your stated requirements. I'd suggest that you go grab npm:standard-nonhorrible as it's still available :p

[ghost]

Some items I mentioned here are quantifiable metrics.
And "horrible code" can be subjective, but the criteria I mentioned is not subjective.

standard achieves not much in terms of quality, as opposed to this claim from your README.md file:

This module helps hold our code to a high standard of quality.

What I suggest you to do, is to create levels:
standard level 1 can be just the code style.
standard level 2..n can be more strict and actually reflect high quality.

[zanona]

@arboreal84, by any chance would you be able to share the ESLint rules for your suggestion?
@jprichardson how would you recommend extending these rules into standard?
Thanks in advance

[ghost]

(Well first of all, sorry for the initial tone, edited the message).

• maximum statements per function
  https://eslint.org/docs/rules/max-statements

• maximum cyclomatic complexity per function
  https://eslint.org/docs/rules/complexity

• assignments to function parameters
  https://eslint.org/docs/rules/no-param-reassign

• statement length (through line length)
  https://eslint.org/docs/rules/max-len

Now there's also "prefer constants", which will let you know if a variable can be turned into a const.
More enforcement than this can be hard to achieve in JS.
https://eslint.org/docs/rules/prefer-const

To my knowledge there's no static analysis for numbers, dates, etc.

Cons

The cons of this approach is: there can be bikeshedding about the thresholds, since this could be read as a vague predicate.

e.g: how many statements per line are allowed, how much cyclomatic complexity, etc.

It can be initially set very high, to block the unreasonably complex code. Then probably find a balance.

[zanona]

Thanks a lot for sharing those @arboreal84, it's super helpful.
Now it would be great to hear from @jprichardson what's the recommended way to extend these into standard.

The only way I can think of is to have a .eslintrc file only with these declarations and use both eslint and standard to test your code. but then, wouldn't it be better to use https://github.com/standard/eslint-config-standard altogether instead?

[ghost]

Well, as @jprichardson mentioned, the objective of standard is to create some sort of least common denominator that appeals to most people (i.e: maximize adoption), rather than creating a bulletproof standard.

That's why I suggested establishing levels,
e.g:

• standard level 0 = what you have today
• standard level 1 = additional rules with relaxed defaults
• standard level 2 = more rules, more strict defaults

There's a lot of room for improvement with it comes to coding standards and static analysis.

But I guess this will most likely be up to another project.

Thanks for following up this discussion, @zanona.

[feross]

@zanona You may wish to look into standardx which allows you to layer in additional custom rules.