I've been always meaning to try this out but always just keep reusing the ESLint config, which is probably a bit out of date now. So the question is, could someone explain to me (and everyone who has these same thoughts) why is StandardJS worth a try?
If you want a prebuilt eslint config, and you don't like the really popular ones (eg, airbnb[0]) because they default to requiring semicolons, then this is definitely the most popular of the ones that require you to omit semicolons.
Beyond that, there are no advantages. It's just a decent eslint config that requires you to omit semicolons wherever possible. If that's important to you, use it. If it's not important, or you'd rather not omit semicolons, or if you do want to omit semicolons but you're happy making a one line change to the airbnb preset, then there's nothing to set this apart from more, if you'll pardon the expression, "standard" options. :)
You can just disable that rule and use the rest of the airbnb preset, which is what I'd recommend. I hate semicolons, and I do a couple of things that I like but airbnb apparently doesn't, so I override those settings on my .eslintrc and use the rest as a great foundation.
I believe this is just a standard set of rules for ESLint but Prettier is more like gofmt for javascript.
Last I used it Prettier it was very opinionated, but I think you can override it with ESLint rules now which you could use StandardJS to do without needing to write your own.
Prettier is a formatter. It doesn't check for errors, it merely parses JS and enforces a style. It actively corrects any style problems that are found.
Standard is a linter (ESLint) configuration and frontend. It doesn't correct errors, just checks for them. It goes beyond style to actually check for logical errors (usage of deprecated APIs, invalid regexps, etc).
In theory, you can run the two together. Ideally, you'd use plain ESLint with a config geared around catching programming errors, and leave Prettier for just styling concerns.
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.
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.
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.
> 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)
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.
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.
The solution to "forget to run it and break production" is to add the linter to your CI tests, or even as a precommit hook.
I touch on this in my other comment, but it's entirely possible to forget a semicolon and break things no matter which style you prefer. Both semi:always and semi:never+no-unexpected-multiline enforce good standards which can be assimilated; like spaces vs tabs, they're just different standards that people tend to develop very strong opinions about.
Except using semicolons everywhere does not protect you from automatic semicolon insertion. You still need to know the rules. https://feross.org/never-use-semicolons/
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.)
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.
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.
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.
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.
Feross (of YouTube Instant and Webtorrent fame) did a great branding job on this. However, from my own limited experience, this is an unneeded layer on top of the fantastically good ESLint.
I used Standard for a while, because it matched my personal preferences almost 100%. Some day, however, I decided to do a small modification. Now I'm alone with my own eslintrc and my own dotfiles management.
I used to be on a team that wrote JS this way and I really enjoyed it. Now I'm in a Flow/React/semicolons-and-classses-everywhere type place. I find this style so much more pleasant.
Kinda. But not. Statements have little to do with lines, and they span lines very often. Variable declarations, especially objects and arrays. Many times for method calls too with many arguments. Kinda.
Obviously it's a preference. But you proved my point to me, your "sentences" look sloppy and incomplete. I try not to write like that, why would I code like that?
Its a good question readers of the English language can also infer punctuation where needed it's not considered good style to make readers infer this there can be some oddness if you are not used to putting punctuation where it belongs naturally garden path sentences can result and some tools can detect ambiguity automatically but why learn some custom rules for that when its straightforward to consistently put periods at the end of sentences
Except that 'punctuation' in JavaScript comes in the form of a line break, and adding a semicolon is like adding two periods to the end of every sentence just in case someone missed the first one.
Because JS syntax is copied from Java that uses semicolons. Omitting semicolons makes code more ambigious and one has to remember where they can and where they cannot break a line.
JS is not a language like Ruby or Python.
If someone doesn't like typing semicolons why don't they set up their editor so that it would insert them automatically?
Your previous comment read like you now were okay with semi-colons, but I realized now that it's you like no semi-colons. But, in my opinion, the reason you'd be okay with looking at it if you didn't have to is if you wanted to!
JS will add the semicolons. If you're using Babel and the rest you most likely are not going to run into all the weird things to do with semi-colons as long as you follow K&R C style for control statements.
But if you want it to, go ahead. What matters, in the end, is consistency to make it look pretty. The more it looks like a single very smart person wrote it the better.
So what's the goal of this project? From the announcement it says
there are lots of new rules in 10.0.0 designed to help catch bugs and make programmer intent more explicit.
Then in the FAQ it says
Can I use a JavaScript language variant, like Flow?
Before using a custom JS language variant, consider whether the added complexity (and effort required to get new contributors up-to-speed) is worth it.
The goal of variants like Flow is to catch bugs and make intent more explicit! We have to consider if it's worth training up new contributors on this, but we don't have to consider the contributor cost to learn all of feross's personal JS style preferences and API opinions?
I get the goal of having a uniform style - that's important and valuable, even though StandardJS's decisions don't match the style predominant in the JS community. But it seems like there's been a lot of scope creep here where now there are specific rules for specific APIs and other stuff that is well outside the domain of "Let's all format our code the same".
Flow doesn't run on my home computer nor in my personal VPS I use for development. It also doesn't run in my Linux girlfriend's computer which I use sometimes, or the computer I sometimes use at work.
even though StandardJS's decisions don't match the style predominant in the JS community
I find it particularly ironic that there's a reasonably popular fork called semistandard. [1]
In all seriousness though, I'd really love to see the JS community move towards tools like prettier[2] instead of continuously trying to establish "one eslint config to rule them all". I just want each repo I work with to configure my editor for me and reformat stuff automatically (a la gofmt) so I can forget about it. Even if some of the particular style decisions are ones that I personally don't agree with, it doesn't matter — the value of having those decisions abstracted away from me in the first place is significant enough that any minor quibbles fade away pretty quickly. Then I can focus on writing and reading code, not on arguing about whether we should enforce or disallow dangling commas in our lint config.
>Even if some of the particular style decisions are ones that I personally don't agree with, it doesn't matter — the value of having those decisions abstracted away from me in the first place is significant enough that those quibbles fade away pretty quickly.
So... Standard?
I use Prettier and pipe the output my own eslint file. Could do the same but Prettier | Standard. Or Semistandard. Or whatever.
The issue is the community largely values their personal styles (ignoring choice of semicolon omission) too much to standardize on "one style to rule them all". Because everyone (including myself) "I like this except these two little things" and everyone's two little things are different so you end up with 200 different lint configs each mostly similar but with their own little tweaks.
I guess what I was trying to say is that I wish the JS world had had its own gofmt/refmt from the get-go. But since it didn't, the community's still pretty undecided more than 20 years after the language came into being, and I don't see that changing significantly any time soon. I don't know, maybe it's "too late"?
Not that I think golang got it exactly right either, but because the style guide was essentially built into the language from the start, the change process is necessarily slower and more intentional, and I think that's a good thing.
I agree. Furthermore, it is really deceitful to use the name "Standard" when it's far from it. For years this was not the standard way of writing JavaScript. I get that standards change. However, this isn't even the way most companies write JavaScript.
The way I interpret this: some group of developers thought it would be a good idea to hijack the word "standard," and wedge this particular new style into the concept. It just isn't standard. It's as absurd as having a company called "Blue Shine" and selling only green colored cleaning products.
At least be honest about it. Call it something else, like "Colonless," since that's the most obvious thing that sticks out when using this style.
This is an awful project. Someone took his own preferences for code style and tries to make it look like some "standard".
The parts that I don't like the most are 2 spaces for indentation (why so small? who else is using such small indentation?) and "no semicolons" rule.
It would be better to adopt some style guide from Java, because JS has similar syntax and because Java has been in use in large projects for a long time.
53 comments
[ 2.9 ms ] story [ 127 ms ] threadBeyond that, there are no advantages. It's just a decent eslint config that requires you to omit semicolons wherever possible. If that's important to you, use it. If it's not important, or you'd rather not omit semicolons, or if you do want to omit semicolons but you're happy making a one line change to the airbnb preset, then there's nothing to set this apart from more, if you'll pardon the expression, "standard" options. :)
[0]: https://github.com/airbnb/javascript
I think airbnb is a really good base for a project.
Last I used it Prettier it was very opinionated, but I think you can override it with ESLint rules now which you could use StandardJS to do without needing to write your own.
Standard is a linter (ESLint) configuration and frontend. It doesn't correct errors, just checks for them. It goes beyond style to actually check for logical errors (usage of deprecated APIs, invalid regexps, etc).
In theory, you can run the two together. Ideally, you'd use plain ESLint with a config geared around catching programming errors, and leave Prettier for just styling concerns.
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
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.
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.
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.
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)
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.
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 )
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.
I touch on this in my other comment, but it's entirely possible to forget a semicolon and break things no matter which style you prefer. Both semi:always and semi:never+no-unexpected-multiline enforce good standards which can be assimilated; like spaces vs tabs, they're just different standards that people tend to develop very strong opinions about.
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.)
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.
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.
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.
Seems like a silly conclusion
Except that 'punctuation' in JavaScript comes in the form of a line break, and adding a semicolon is like adding two periods to the end of every sentence just in case someone missed the first one.
This sort of writing generally leaves off periods on the ends of sentences
sometimes, it even leaves off the capitalization at the beginning, as well
and yet it manages to be entirely readable and generally unambiguous
This is remarkably similar to js's automatic semicolon insertion:
if the sentence makes more sense with a period at the end of the line
then the reader usually inserts one automatically, without thinking about it
JS is not a language like Ruby or Python.
If someone doesn't like typing semicolons why don't they set up their editor so that it would insert them automatically?
JS will add the semicolons. If you're using Babel and the rest you most likely are not going to run into all the weird things to do with semi-colons as long as you follow K&R C style for control statements.
But if you want it to, go ahead. What matters, in the end, is consistency to make it look pretty. The more it looks like a single very smart person wrote it the better.
I get the goal of having a uniform style - that's important and valuable, even though StandardJS's decisions don't match the style predominant in the JS community. But it seems like there's been a lot of scope creep here where now there are specific rules for specific APIs and other stuff that is well outside the domain of "Let's all format our code the same".
I find it particularly ironic that there's a reasonably popular fork called semistandard. [1]
In all seriousness though, I'd really love to see the JS community move towards tools like prettier[2] instead of continuously trying to establish "one eslint config to rule them all". I just want each repo I work with to configure my editor for me and reformat stuff automatically (a la gofmt) so I can forget about it. Even if some of the particular style decisions are ones that I personally don't agree with, it doesn't matter — the value of having those decisions abstracted away from me in the first place is significant enough that any minor quibbles fade away pretty quickly. Then I can focus on writing and reading code, not on arguing about whether we should enforce or disallow dangling commas in our lint config.
[1] https://github.com/Flet/semistandard
[2] https://github.com/prettier/prettier
So... Standard?
I use Prettier and pipe the output my own eslint file. Could do the same but Prettier | Standard. Or Semistandard. Or whatever.
The issue is the community largely values their personal styles (ignoring choice of semicolon omission) too much to standardize on "one style to rule them all". Because everyone (including myself) "I like this except these two little things" and everyone's two little things are different so you end up with 200 different lint configs each mostly similar but with their own little tweaks.
Not that I think golang got it exactly right either, but because the style guide was essentially built into the language from the start, the change process is necessarily slower and more intentional, and I think that's a good thing.
The way I interpret this: some group of developers thought it would be a good idea to hijack the word "standard," and wedge this particular new style into the concept. It just isn't standard. It's as absurd as having a company called "Blue Shine" and selling only green colored cleaning products.
At least be honest about it. Call it something else, like "Colonless," since that's the most obvious thing that sticks out when using this style.
reminds me of the debacle around "Standard Markdown", now called "CommonMark"
The parts that I don't like the most are 2 spaces for indentation (why so small? who else is using such small indentation?) and "no semicolons" rule.
It would be better to adopt some style guide from Java, because JS has similar syntax and because Java has been in use in large projects for a long time.