Proposed JavaScript Standard Style
github.com
github.com
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.
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.
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.
That's just not true. You can have destructuring assignments, not just declarations: `[a, b] = [b, a];` is perfectly legal ES2015.
;[a, b] = [b, a]> i have learned to use them, that's why there isn't one present.
Did you, really? Because that's how that bug came to be. Because of you stubbornly omitting them.
Why do these people want to avoid semicolons at all costs? Even inconsistencies? Even potential bugs? Why?? I just don't get it.
I need to leave this discussion, I'm getting nerd-rage.
;[1, 2, 3].forEach(bar)
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!"
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.
(function(a1, a2) {
// something
})(arg1, arg2); let sql = `delete from order_lines`
` where order_id = ${orderId}`;
This has happened to me with a rather more complex query.
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).
An Open Letter to JavaScript Leaders Regarding Semicolons http://blog.izs.me/post/2353458699/an-open-letter-to-javascr...
JavaScript Semicolon Insertion – Everything you need to know http://inimino.org/~inimino/blog/javascript_semicolons
Are Semicolons Necessary in JavaScript? https://www.youtube.com/watch?v=gsfbh17Ax9I
Spreading FUD doesn't help anyone out.
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.
https://github.com/brave/browser-laptop/blob/master/package....
^ Brendan's own company (Brave) uses `standard`, so it's clear he doesn't think omitting semicolons is so bad.
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.> No decisions to make.
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.
This amused me, as the npm team themselves use `standard`.
Calling this "JS standard!" bothers me to no end. I suppose I have to create my own style and call it "standard" too.
signed, The entire Python community (well, most of us...)
Also, straight quotes as punctuation are ugly; ‘ and ’ look much nicer.
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`.
EDIT: Looks like I should have joined the fight elsewhere in the comments; please redirect discussion here:
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.
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.
YOU'LL PRY THEM FROM MY COLD, DEAD HANDS FIRST
Of course the solution is to create a separate "standard."
I'm going to fork this and create my own standard...
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.
So spaces only for me, thanks.
It's misplaced passion and I don't care.
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.
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).
var
foo = 1,
foo = 2;
I also use spaces for mid-line alignment and tabs exclusively for identation. I think this is called "smart tabs"?
Semantic tabs would be good with consistent culture and tooling behind them.
Never, you fucking monster.
https://github.com/feross/standard/blob/master/package.json#...
but style-guides should be just that style guides ...not standards
Plus then you don't have to talk about it in code reviews. It's not a very interesting topic, honestly.
Downside is that very few other authors are using it, so when you share code people are concerned about its format (no semicolons in particular).
list.map(func1)
.filter(func2)
.map(func3)
.reduce(func4);
EDIT: Ah, thanks – the things I read never mentioned JS doing lookahead during ASI. This makes it a lot nicer, tbh.
The code works as expected.
[0] Not true for "restricted productions", which include naked returns, and some other "special" cases.
Would
return list.map(func1)
.filter(func2);
return
list.map(func1)
.filter(func2);
Here is an example: http://jsbin.com/mokipigeqa/edit?html,js,console
Here are the ASI-relevant parts of the ES5 standard: http://es5.github.io/#x7.9
In JavaScript, LineTerminators are used as a separator between tokens, just like other whitespace is. Therefore:
list .map() .filter()
list
.map()
.filter()I disagree with some of the rules, but there's clearly merit to having one opinionated, zero-configuration linter-enforced style.
edit: ha, I got downvoted for saying something is good and recommending it. You guys are silly