3 ms·

StandardJS is like TornadoGuard from xkcd. https://xkcd.com/937/ https://xkcd.com/937/ Very good reviews, but it doesn't achieve the grandiose things it claim

StandardJS is like TornadoGuard from xkcd. https://xkcd.com/937/ https://xkcd.com/937/ Very good reviews, but it doesn't achieve the grandiose things it claims to achieve. While consistent indentation is important, a coding standard is much more than that. I consider this to be an actual standard: https://google.github.io/styleguide/jsguide.html https://google.github.io/styleguide/jsguide.html For example Python enforces consistent indentation, but you know that there is still a lot of room to create a mess even with those restrictions. StandardJS was designed to maximize adoption, not to ensure actual quality: - Want a 1,000 characters long line of code? StandardJS badge of approval. - Want a 10,000 lines of code function? StandardJS badge of approval. - Want a function with a cyclomatic complexity of 10,000? StandardJS badge of approval. Those are very basic measures of code quality and StandardJS does not have an actual position about them. Then... StandardJS actually goes against good practices. Omitting semicolons actually has an effect in JavaScript, and there are many examples of that. The Google JavaScript coding standard advises specifically against it for good reasons. Remember that Google created v8, and has a lot more authority in this matter than whoever created StandardJS. ESLint can enforce a cyclomatic complexity limit, number of statements per function, lines per file, etc.

conradk 10y ago
It may not be perfect for everyone, but in that case, no need to rage. You can just use any of the 38472647893242 different linters out there. What I like about StandardJS is that I don't need yet another config file just for a linter. lintrc, babelrc, webpack.config.js, karma.config.js, etc, etc. Having one less thing for people to need to understand is a nice feature in and of itself IMO. And I actually tended to disagree with some of the StandardJS choices before adopting it. After working with it for a few weeks, I realize it makes absolutely no difference. I just have a linter that works with no config.
- partycoder 10y ago
  For me StandardJS is the same as having no linter at all, because it doesn't take action on the problems that can be actually harmful, like the ones I mentioned. An excessively long function, statement or a complex function is a liability because it almost certainly cannot be tested or reasoned about. And all the negative consequences of not being able to test or verify code.
betenoire 10y ago
> Omitting semicolons actually has an effect in JavaScript, and there are many examples of that. The Google JavaScript coding standard advises specifically against it for good reasons. I just gave Standard a try for the first time, kinda surprised I'd never seen it til now. Anyway, it seems to also check for those semi-colon gotchas. If I try to use no-semicolons incorrectly, it catches my mistake. (I tried by putting the return value on the next line)
- partycoder 10y ago
  Hopefully one day you don't forget to run it and break production :) Usually good standards can be assimilated and make you code in a safer way, even if not enforced by a tool. You could argue that a script, version control hook or continuous integration script can take care of it, but those are lines of defense that can go away in certain circumstances and you are unnecessarily raising your odds for an incident. Sometimes people add a block comment to disable linting, and if you were relying on your linter to provide the fix to allow your bad habit of not using semicolons, then you are on your own.
  - betenoire 10y ago
    Personally, no semi colons is a deal breaker for me. It's like a period at the end of the sentence that means, "That's the entire statement". So, it's neat in the config-less way, but I won't be using it. (there is a semicolon version by the way https://github.com/Flet/semistandard https://github.com/Flet/semistandard )
    - partycoder 10y ago
      Still with semicolons, many core problems remain: it's too permissive, and it's designed that way to maximize adoption. If StandardJS was a standard for dating, its only filter would be that your potential date is alive and is a mammal. Use that Standard and you will have a lot of potential dates! such a great standard.
  - wolfgang42 10y ago
wolfgang42 10y ago
There's a lot of FUD around Automatic Semicolon Insertion for some reason. Basically, the parser inserts a semicolon anywhere where the program is otherwise unparseable but a semicolon would make it syntactically valid. Importantly, this will occur even if you are otherwise using semicolons, so simply saying that you need to manually put the semicolons in doesn't help the situation since the parser may add them for you in places you didn't expect anyway. Leaving them out forces you to know the rules, but you should have known them anyway since otherwise they will bite you at some point. ESLint provides--and StandardJS uses--the `no-unexpected-multiline` rule, which will insist that you insert semicolons in places where the meaning would otherwise be unexpected. In practice, with `semi` set to never and `no-unexpected-multiline` enabled, I find that I have never had a problem with semicolons that was not caught by the linter. By contrast, when I was afraid of ASI (since "omitting semicolons actually has an effect", eek!) I would find that I'd occasionally have mysterious issues where arrays were interpreted as indexes and so on. (I switched to semicolonless-style at the same time as I started using a linter, so I can't compare the two independently.)
- partycoder 10y ago
  There's a lot of FUD around not using a seat belt. Basically, if you are careful to not crash your car, your seat belt should not be necessary. You can die even if using a seat belt. My standard of car safety relies on that each time you crash your car, a red light will flash telling you that you have crashed your car. It is very effective detecting car crashes, therefore, very safe.
  - randallsquared 10y ago
    Hm. In the case where the ASI inserts a semicolon where you wouldn't have expected one, how do the semicolons you already added where you would expect them help? Using semicolons in JS to avoid problems is like making sure the seatbelt is securely fastened across the seat before you sit down: there's a satisfying click and the worrying light on the dash goes off, but it won't actually protect you in an accident.
wolfgang42 10y ago
Cyclomatic complexity seems difficult to lint. I tried, briefly, and decided that linters were much better more for catching mechanical problems than stylistic ones. Where do you set the line? 10? What happens if you have a function that's got a complexity of 11? Do you have to split it? What if that makes the code harder to read? Maybe this makes more sense in a codebase where there's a variety of contributors of differing skill levels. I'm interested to hear about how other people use measures of complexity and function size.
- partycoder 10y ago
  Sure, you can create a Sorites paradox out of this... https://en.wikipedia.org/wiki/Sorites_paradox https://en.wikipedia.org/wiki/Sorites_paradox Eventually you will have to commit to an arbitrary value, and stick to it. But there are cases in which it's no longer subjective if cyclomatic complexity is bad. If you have a 500 lines of code function with 50 return points and cyclomatic complexity of 100 it is very clear there is no way you can maintain that or write a unit test for it without playing Russian roulette each time you check in a change and therefore you can objectively say that code is not safe and should not be allowed.

conradk 10y ago

It may not be perfect for everyone, but in that case, no need to rage. You can just use any of the 38472647893242 different linters out there. What I like about StandardJS is that I don't need yet another config file just for a linter. lintrc, babelrc, webpack.config.js, karma.config.js, etc, etc. Having one less thing for people to need to understand is a nice feature in and of itself IMO. And I actually tended to disagree with some of the StandardJS choices before adopting it. After working with it for a few weeks, I realize it makes absolutely no difference. I just have a linter that works with no config.

partycoder 10y ago
For me StandardJS is the same as having no linter at all, because it doesn't take action on the problems that can be actually harmful, like the ones I mentioned. An excessively long function, statement or a complex function is a liability because it almost certainly cannot be tested or reasoned about. And all the negative consequences of not being able to test or verify code.

betenoire 10y ago

> Omitting semicolons actually has an effect in JavaScript, and there are many examples of that. The Google JavaScript coding standard advises specifically against it for good reasons. I just gave Standard a try for the first time, kinda surprised I'd never seen it til now. Anyway, it seems to also check for those semi-colon gotchas. If I try to use no-semicolons incorrectly, it catches my mistake. (I tried by putting the return value on the next line)

partycoder 10y ago
Hopefully one day you don't forget to run it and break production :) Usually good standards can be assimilated and make you code in a safer way, even if not enforced by a tool. You could argue that a script, version control hook or continuous integration script can take care of it, but those are lines of defense that can go away in certain circumstances and you are unnecessarily raising your odds for an incident. Sometimes people add a block comment to disable linting, and if you were relying on your linter to provide the fix to allow your bad habit of not using semicolons, then you are on your own.
- betenoire 10y ago
  Personally, no semi colons is a deal breaker for me. It's like a period at the end of the sentence that means, "That's the entire statement". So, it's neat in the config-less way, but I won't be using it. (there is a semicolon version by the way https://github.com/Flet/semistandard https://github.com/Flet/semistandard )
  - partycoder 10y ago
    Still with semicolons, many core problems remain: it's too permissive, and it's designed that way to maximize adoption. If StandardJS was a standard for dating, its only filter would be that your potential date is alive and is a mammal. Use that Standard and you will have a lot of potential dates! such a great standard.
- wolfgang42 10y ago

wolfgang42 10y ago

There's a lot of FUD around Automatic Semicolon Insertion for some reason. Basically, the parser inserts a semicolon anywhere where the program is otherwise unparseable but a semicolon would make it syntactically valid. Importantly, this will occur even if you are otherwise using semicolons, so simply saying that you need to manually put the semicolons in doesn't help the situation since the parser may add them for you in places you didn't expect anyway. Leaving them out forces you to know the rules, but you should have known them anyway since otherwise they will bite you at some point. ESLint provides--and StandardJS uses--the `no-unexpected-multiline` rule, which will insist that you insert semicolons in places where the meaning would otherwise be unexpected. In practice, with `semi` set to never and `no-unexpected-multiline` enabled, I find that I have never had a problem with semicolons that was not caught by the linter. By contrast, when I was afraid of ASI (since "omitting semicolons actually has an effect", eek!) I would find that I'd occasionally have mysterious issues where arrays were interpreted as indexes and so on. (I switched to semicolonless-style at the same time as I started using a linter, so I can't compare the two independently.)

partycoder 10y ago
There's a lot of FUD around not using a seat belt. Basically, if you are careful to not crash your car, your seat belt should not be necessary. You can die even if using a seat belt. My standard of car safety relies on that each time you crash your car, a red light will flash telling you that you have crashed your car. It is very effective detecting car crashes, therefore, very safe.
- randallsquared 10y ago
  Hm. In the case where the ASI inserts a semicolon where you wouldn't have expected one, how do the semicolons you already added where you would expect them help? Using semicolons in JS to avoid problems is like making sure the seatbelt is securely fastened across the seat before you sit down: there's a satisfying click and the worrying light on the dash goes off, but it won't actually protect you in an accident.

wolfgang42 10y ago

Cyclomatic complexity seems difficult to lint. I tried, briefly, and decided that linters were much better more for catching mechanical problems than stylistic ones. Where do you set the line? 10? What happens if you have a function that's got a complexity of 11? Do you have to split it? What if that makes the code harder to read? Maybe this makes more sense in a codebase where there's a variety of contributors of differing skill levels. I'm interested to hear about how other people use measures of complexity and function size.

partycoder 10y ago
Sure, you can create a Sorites paradox out of this... https://en.wikipedia.org/wiki/Sorites_paradox https://en.wikipedia.org/wiki/Sorites_paradox Eventually you will have to commit to an arbitrary value, and stick to it. But there are cases in which it's no longer subjective if cyclomatic complexity is bad. If you have a 500 lines of code function with 50 return points and cyclomatic complexity of 100 it is very clear there is no way you can maintain that or write a unit test for it without playing Russian roulette each time you check in a change and therefore you can objectively say that code is not safe and should not be allowed.