No semicolons? REALLY? We've already spoke about this, people.
Let's see what Brendan Eich has to say about this:
> My two cents: be careful not to use ASI as if it gave JS significant newlines. [1]
and
> ASI is (formally speaking) a syntactic error correction procedure. If you start to code as if it were a universal significant-newline rule, you will get into trouble.
Calling it "standard JS" struck me as pretentious at first. But calling it "standard JS" and calling for not using semicolons is absolutely delusional.
Let me be clear here:
- ASI (Automatic semicolon insertion) is a correction mechanism, designed to prevent silly errors, thus making the language "friendly".
- ASI does not work in many cases, where you do need a semicolon. So much for consistency!
All the rest of things in that list are just a matter of personal preference, but not the semicolons though. That's just plain wrong. And if people begin using this "standard" the bugs will come to bite them.
I know I can write a working JS application without semicolons, however I can also write a working JS application where with `eval` and `with`.
The issue is not whether or not one individual can learn to use dangerous feature X. If you are writing code by yourself for your own use, you can use nested eval's and no semicolons with a little bit of `with` here and there, nothing wrong with that. However when you are writing code that is supposed to be developed by people other than you, you might want to write less clever code.
I could write code without semicolons, however that would mean that I would have to constantly keep an eye out for that case where I absolutely need to add it to prevent ASI from doing the wrong thing. It takes probably 100ms to hit that semicolon key, however it takes a lot more time to debug code without semicolons.
If you hat semicolons with a passion for some reason, you could use Coffee Script or some other language which was designed without semicolons and has clear semantics around it.
I think the keyword in Brendan Eich's article is maybe "be careful" rather than "don't use". Overall, Brendan Eich is mostly positive on ASI (otherwise the language wouldn't have it) and some of the article is about how if things had been left to cook longer it's just as likely JS would be a more newline-sensitive language than it is.
Particularly interesting too in the article linked is the link to the paren-free strawman proposal [1] that suggests maybe its past time that JS also drop the algol-family heritage require parentheses in the head of for/while/if for whitespace sensitivity instead (ala CoffeeScript, golang).
Now I have 4 extra rules to remember and destructuring, amongst other things, will look like shit. And for what gain? If there was an actual gain to leaving out the semicolons, I'd be onboard but the only gain here is someone's aesthetic pleasure and someone else's aesthetic displeasure. Last time I checked, code was there to do things, not look pretty. Making the former more difficult to achieve the latter is not only stupid, it's impossible because now you're pandering to fashion which varies from person to person. Also, it's bikeshedding. As if Javascript didn't have real problems it needs solved.
It's one "extra" rule. I call it the "Winky Frown Rule" or you could less cheekily refer to it as something of a "Complete Emoji Rule": lines that start with frowns (, [, ` should be winky frowns: ;(, ;[, ;`
95% of the time I ever use a winky frown is Typescript type assertions ;(<any>someObj)...
It doesn't impact destructuring at all because destructuring lines start with let (or const, or maybe var if you are feeling old school that day).
ASI is not very different at all from the newline rules in Python, ML, Haskell, et al... Freedom from semicolons makes ES2015 feel like the OCaml derivative it always sort of has been.
Everything will be fine if you don't use semicolons. My team and I haven't, for years now. It's really, really, truly honestly ok. I promise. (Only exception is for-loops)
According to the link, you have resort to this kind of weirdness in order to reliably omit semicolons.
;[1, 2, 3].forEach(bar)
To my eye, having that in my code looks far worse than just using "standard" (ha ha) semicolons.
You mention a for loop exception as well. I don't understand what that exception is, but the general message seems to be "Trust me, you can totally omit semicolons! Everything is ok! Except for all these weird edge cases, but you can just hack kludges around them!"
(Apologies for the delay, I had to wait to respond since the lovely people in this discussion have downvoted me)
Yes, people like to bring up these goofball edge cases that don't actually happen in real life. Tell me, when was the last time you mapped over an array literal?
I'm serious, it has been years now, it is ok not to use semicolons in Javascript. People just need to... unclench. It is ok not to use them. I don't know what hellfire and brimstone people expect to happen when they stop using semicolons but it isn't going to happen.
The for-loop thing is that semicolons are required to delimit the initialization, condition, and increment of a for-loop. So you use them there.
See, this is the thing - not using semicolons to terminate statements is nicer than using them (pure opinion of course), and it doesn't cause problems in practice. But it would be ridiculous to take some hard-line stance of "absolute zero semicolons ever". The point is not that we hate the semicolon glyph or something, the point is that you don't need them to terminate statements, so we don't.
That can be good, certainly Go developers benefit from the lack of bikeshedding over style.
But the authors of standard didn't take this advise; they did make decisions, the ones that they prefer. If they would have just grepped through NPM to figure out the most popular style choices I would have respected the idea a bit more.
The reason Go is known for this is the gofmt tool. Until there's a good equivalent for JS, thousands of man-hours will continue to be wasted on style-related nonsense like this.
Grep through the npm ecosystem, as that serves as a large sample size of what are the standard style choices. I know that npm and it's largely unreadable codebase uses your style.
But this isn't a real web standard!
Of course it's not! The style laid out here is not affiliated with any official web standards groups, which is why this repo is called feross/standard and not ECMA/standard.
The word "standard" has more meanings than just "web standard" :-) For example:
This module helps hold our code to a high standard of quality.
This module ensures that new contributors follow some basic style standards.
I don't claim a project has to be an "official" Web standard to be a standard, but I'm seeing a hard time how this one is a standard in any meaningful sense.
No semicolons, two space indentation, space after function name, single quotes for strings? There's no way this would fly with a majority of developers.
I really really don't understand space indentation over tabs. Every editor known to man allows you to set tabs to display with as many spaces as your heart desires. You like four spaces? Great! You like 2? Not my cup of tea, but OK! You like 8? Weirdo, but whatever! As long as your editor spits out tabs, then we can all live in harmony!
EDIT: Looks like I should have joined the fight elsewhere in the comments; please redirect discussion here:
singlequotes for strings is very much a standard thing in JS. And two space indentation is fairly common as well. The no semicolons and space after function name are really the weird things here.
Why would you prefer single quotes over double quotes? An apostrophe is not just punctuation in English, it is necessary to preserve the meaning of certain words (like "its"/"it's"). So in a way, it can be considered to be another, albeit rare, letter of the alphabet. Now if somebody proposed to delineate strings with the character "x" everyone would agree it's a bad idea. For the same reason, using "'" to delineate strings is also bad, and shouldn't be encouraged.
There's also the subtle laziness that double quotes require an extra keypress (Shift). It's not a great reason to prefer single quotes over double quotes, but it is a useful reason if you are writing a lot of strings.
JS has a lot of things that key off strings (because it doesn't have a proper enum type and the Symbol type is too new for a lot of usage yet), so you type a lot of "non-English text" strings, so single quotes make a lot of sense for the majority of uses of strings in JS. English text I typically still "double quote" or `template string quote`.
I thought so too at first, as those were the only things that disagreed with my previous style. However, I've been using "standard" for a bit now, and have to say that both of those decisions have really grown on me in light of ecma2015 features. Space after function name works well with generator functions and yield. Semicolon placement has become somewhat less consistent with the new object literal and class syntax and skipping them everywhere has saved me from constantly trying to remember whether I need one after a particular function or method definition.
Funny that a project that is supposed to fight debates about style, creates so much debate!
As a experience of actually adopting standard (this very project) in a company, I must say it's refreshing to not having any discussions about coding style anymore.
Process before was to discuss which eslint rules we want to follow and then sometimes it changes. With "standard", we just asked ourselves "Can we adopt these rules and stand with them?". Most people agreed and then we implemented the support company wide and now we never discuss coding style in our javascript projects anymore, which is a pleasure.
If you find yourself discussing coding styling, see if you can adopt something like standard, and then just go with it.
While I'm not the biggest fan of this style, mostly because of the semicolon thing, I like packages like these.
When you're starting a new project with more than one developer you're going to run into people talking about this stuff more than actually making the project. Pre-bundled linting rules just gets everyone on the same page immediately and stops all the discussion.
I honestly don't care what the style is, 99% of them are sane and readable, consistency is what matters. Nothing worse than working in a project with 5/no styles all over the place.
Maybe if I was using Python or Ruby. But JS? REALLY ugly practice. Multiple blank lines not allowed? I usually go with two to segment heavily procedural code. The most appalling thing by far though is spaces instead of tabs... what's wrong with this guy?
I am well aware that we are in the minority when it comes to preferring tabs over spaces in JS, but, as useless as this decision is, I will fight over it the street.
I'll join that fight, unless you want you your tabs showing up as two spaces instead of four. Then we'll have to fight after we take down the spacers.
On a slightly more serious note, the benefit of tabs is so clear: everyone can have whatever spacing they want and it doesn't affect anyone else. You just configure your IDE and it looks the way you want it to look. For whatever reason, indenting two spaces makes it hard for me to read code.
I've always found the dislike of tabs to be quite strange. Developers love being explicit and semantic about things, and here we have a character that represents a semantic indent, and there's a huge swath of developers who prefer to go with the airy-fairy presentational space character instead. It even solves the 2-vs-4 debate with allowing each user to render it how they will. Heck, you could even render it as three spaces if you will!
It baffles me. Of course, at the end of the day it's just one IDE setting and I don't have to worry about it (we uses spaces at work and it's fine).
I don't really care if people use tabs or spaces as long as the codebase is consistent, but aligning things in the middle of a line is my pet peeve. It's fiddly to maintain, it ruins source control because it requires you to edit many lines when you change one, and worst of all, it makes it impossible to use a proportional typeface.
It's very common to find mixed tabs and spaces where people use tabs. The first sign of this is inconsistent indentation. Maybe they're just sloppy? Oh, hm, here's some more code where it's wildly inconsistent. Time to play guess-the-tab-width until it settles down. Now should I add a comment at the top to tell Emacs about this setting next time I open the file? Probably not, sigh.
Semantic tabs would be good with consistent culture and tooling behind them.
I alternate between projects with and without semicolons, and I'm yet to run into a single error as a result of omitting a semicolon. I don't understand what kind of code other people are writing that does.
I actually got into a Twitter argument with Brendan Eich over it - he more or less won with the note that the tab key in most web editors switches input.
Seems like s fairly poor argument, considering most development wouldn't/shouldn't happen in a web textarea. Also, it's trivial for web editors to solve this themselves - any that don't are just lazy.
I used to like tabs. Then you have a person or two with different tab widths, and some spaces get mixed in, and the beauty of the idea flies out of the window. I've been all spaces for a long time now.
Different tab widths are a non-issue. Sure, the maximum character per line only works for a set tab width, but I take that “problem” over the rigidity (and unsuitability) of spaces as indentation.
It becomes issue when mixed with spaces. Say, aligning function parameters on multiple rows. If the indentation of the second row of parameters is mainly with tabs, and then adjusted to place with spaces, it's suddenly a huge issue. And that will happen.
I always use a tab and set the IDE to show two spaces for each tab. Visual Studio has a setting for this. In the same project if someone wants 4, they can just change it to 4 spaces. In the file, its always stored as a tab
No it's not, because it's not just an editor configuration, it's something in the code structure. People with different indentation working on the same files is a problem, so it's really relevant to try to set a standart about this, at least for open source project.
The idea is that you stop trying to have humans match the style guide, playing trial-and-error with the linter, and instead just have a tool fix the style. We have more interesting problems to solve than matching the style guide. Computers can take care of that.
Plus then you don't have to talk about it in code reviews. It's not a very interesting topic, honestly.
It depends on the engine, but most, when parsing, will look-ahead and see that `.` in `.filter(func2)` is an invalid start to an expression and assume it is part of the previous line.
I've been lucky enough to avoid having to deal with a style guide in a long time. The general idea is sound, but such a guide is always accompanied by hours-long meetings of senior developers hurling their egos at each other over an issue like semicolon usage. Such a waste of everyone's time.
Yeah, that's the whole point of this "standard" project. So instead of adopting for example eslint and then sit in a meeting and decide which rules to follow or not, you adopt standard and say, we are using this now, deal with it.
I mean, eventually you've got to make decisions; you can't all just be writing with your own style (I've experienced that scenario and it really obscured meaningful changes to have tons of style changes in each commit)
In case it's not obvious, this is definitely not a "standard" of any kind. It was named "JavaScript Standard Style" as a joke, and has since become moderately popular.
I disagree with some of the rules, but there's clearly merit to having one opinionated, zero-configuration linter-enforced style.
This seems like a great style, but it's not going to catch on because it's a separate dependency. If this were distributed as a configuration file for the most commonly used linters, I'd be interested. Since it's its own linter with its own plugins etc, hard pass.
Why is this posted under the title "Proposed JavaScript Standard Style"? I am the author of `standard` and I did not propose that this becomes any kind of official JavaScript style standard. It's just my own code standard -- you're free to use it if you want.
The title is misleading. This isn't "proposed" in any relevant standards body. The project itself has a misleading name too, because it's not "standard" in any meaningful way, it's just a set of questionable personal preferences.
We have been using for some time js-beautify [1] together with a pre-commit hook to enforce the style of our JS code.
This doesn't seem much different, am I missing something ?
Let's see what Brendan Eich has to say about this:
> My two cents: be careful not to use ASI as if it gave JS significant newlines. [1]
and
> ASI is (formally speaking) a syntactic error correction procedure. If you start to code as if it were a universal significant-newline rule, you will get into trouble.
Calling it "standard JS" struck me as pretentious at first. But calling it "standard JS" and calling for not using semicolons is absolutely delusional.
Let me be clear here:
- ASI (Automatic semicolon insertion) is a correction mechanism, designed to prevent silly errors, thus making the language "friendly".
- ASI does not work in many cases, where you do need a semicolon. So much for consistency!
All the rest of things in that list are just a matter of personal preference, but not the semicolons though. That's just plain wrong. And if people begin using this "standard" the bugs will come to bite them.
[1] https://brendaneich.com/2012/04/the-infernal-semicolon/