January 24, 2012 at 00:01Open letter to JS leaders regarding semicolons
- Transfer
I received this letter from Sean Silva last night:
I wrote a few paragraphs, and decided to shorten them to the following answer:
Inimino posted a very clear explanation . In his style - clear, concise, authoritative, with good research - and he, as always, left his opinion to himself.
I am going to be a little more biased.
The first rule is pretty obvious. Even JSLint does not mind characters
The second is very strange. I have never met such things (with the exception of such conversations) that someone wanted to write
Third is well understood, although it is usually neglected:
The fourth, usually FUD- inspired, “oh no, you need semicolons!” Is the case. But it turns out that it’s quite simple to precede such lines with semicolons, if you did not want to make them extensions of the previous ones.
For example, instead of:
The advantage is that prefixes are easier to notice since you decide to never start a line with
Aligning the most important tokens on the left side of the screen makes them clearly easier for people to quickly analyze. Piles of quick reading studies and eye movements claim that missing a token on the right is more likely to be overlooked than a missing token on the left. So - I repeat - move less important things to the right, and put more important things on the left.
I can guarantee that, no matter how little it worries you, your JS code worries me less than you care about mine. This is not an article where I try to convince you to write code in my style. Everyone must decide what is the policy of wearing pants in his house .
As a manifestation of goodwill ...
"I put semicolons in JS, because otherwise it would not be valid C / C ++ / Java / Anything else." If you have to write a lot of Java or C code in a project and want your JS not to stand out too much, then this is a worthy argument. (The Cassis project brings this argument to an absurd conclusion.)
“We do this because we use the linter, and the linter tells it to.” Consistency is important, and linter is one way to achieve code consistency for a group. The task of writing an npm-compatible linter is on my todo list, but not very high.
These rules go back to the dawn of JS, to the late 90s. They are not new, and my opinion is that there is no forgiveness to anyone who calls himself a professional in JS and does not understand the rule of terminating expressions. It is frankly irresponsible for the leaders of the JS community to continue to spread obscurity instead of understanding.
Moreover, the typical place where AIS attacks stealthily is limited rules. Adding semicolons in each line will not force you to
The only way foreverprevent errors with limited rules - always use semicolons and never put line breaks . No one offers this. So stop talking about it as if it matters, or suggest redundant semicolons as an alternative to understanding ASI. You must understand ASI in order to be a competent JS programmer, period.
And that leads us to ...
I think I just insulted you. Very sorry. I know that you know a lot of things about JS - such as DOM, and CSS, and MSIE bugs, and jQuery. You probably spent some time studying closures, and prototypes, and scopes, and activation objects, and even wrote some extensions for V8 or SpiderMonkey. You are not stupid, I'm sure. In fact, you are most likely smarter than me, and you are probably nicer and better looking. I am sure that we have a lot in common, and we could be friends.
But if you do not understandwhat an expression in JS is , in your understanding of what is perhaps the most fundamental aspect of the language - a huge hole.
And this is normal. I do not speak Spanish very well and my C is generally at the beginner level; and I do not call myself an expert in these things, although I know enough to get out in most situations. If I was going to work, which implies a lot of conversations in Spanish or a lot of C, I would like someone to look after me to help avoid some serious mistakes.
Like most things in JS, expression termination rules are not well designed, but they are not very difficult to understand and use. This understanding just takes a little time and effort.
Sit back with hot chocolate and the ECMAScript spec some Saturday night. Practice it. Play with the test programs. This is a good pastime.
Or do not do this if you do not want to. This is your life. Surely you have better classes.
Just stop making authoritative statements like "end all lines with semicolons to be safe." This is not safer and not safer.
Because there are so many of them, and I do not know them all.
If you wrote on JS for a while, and give advice or lead someone with less experience, then I will contact you. Being a leader is a responsibility. Take this seriously. Do not spread the lie. Be an expert, or admit that you are not. But do not drive this car without a license.
JavaScript is not English. We also do not denote possession (or the object-verb relationship) with a dot in English. There are no object literals in English, and we indent only the first line of a paragraph, and not all sentences.
This is such a stupid argument that I have no choice but to fall in love with him.
I began to insult you, but you won my heart, Adept of Literate Programming. From now on, I will put line feeds only at the end of functions, not in the middle, and indent on the first line of each of them.
Write the code as you want. I don't care a bit.
Just please don't lie to people. That is all I ask. This is just a little courtesy. This is not difficult. Just tell the truth instead of lying - that’s what I’m talking about.
(from the translator: as a translator, I want to express my gratitude for the help with the translation and proof-reading to my beloved woman - philologist)
I looked through your code for the npm.js project (in particular, this file: https://github.com/isaacs/npm/blob/master/lib/npm.js ) and noticed that you are aligning commas to 'r 'in var expressions, and under [and {in array / object literals. I really like this formatting method, but I hesitate to use it, since most resources about js instill fear of chaos that reigns in the code due to automatic semicolons if you do not end the lines with anything that suggests continuation.
Is it safe to place commas this way in “browser” code, or is it only possible in node?
I wrote a few paragraphs, and decided to shorten them to the following answer:
Yes, it is completely safe, and it is a completely valid JS, understood by every browser. Closure compiler, yuicompressor, packer, and jsmin - all can properly minify it. Performance is not going anywhere.
I'm sorry that instead of educating you, the community leaders in this language instilled in you lies and fears. It's a shame. I recommend that you study how the instructions in JS are actually terminated (and in which cases they are not terminated) - and you can write code that you find beautiful.
Inimino posted a very clear explanation . In his style - clear, concise, authoritative, with good research - and he, as always, left his opinion to himself.
I am going to be a little more biased.
rules
In general, it\nalways finishes expressions, except in the following cases:- An expression carries an unclosed parenthesis, an array literal, an object literal, or ends in any other way that is not a legal way to close an expression (for example, ends with
.or,); - The string is
--,++(in the event that the next token is decremented / incremented); - This
for(),while(),do,if(), orelse, and on the line no{ - The next line begins with the
[,(,+,*,/,-,,,., or any binary operator, which can be located in the same expression only between two tokens.
The first rule is pretty obvious. Even JSLint does not mind characters
\nin JSON, in parenthesis constructs, and in var-expressions that span multiple lines ending in ,. The second is very strange. I have never met such things (with the exception of such conversations) that someone wanted to write
i\n++\nj, but, in fact, it is parsed as i; ++j, and not as, the i++; jThird is well understood, although it is usually neglected:
if (x)\ny()equivalent if (x) { y() }. This construct does not end until a block or expression is encountered. ;is a valid JavaScript expression, so it’s if(x);equivalentif(x){}or “if x, do nothing.” This usually applies to loops in which checking is also an update to the counter. Unusual, but found. The fourth, usually FUD- inspired, “oh no, you need semicolons!” Is the case. But it turns out that it’s quite simple to precede such lines with semicolons, if you did not want to make them extensions of the previous ones.
For example, instead of:
foo();
[1,2,3].forEach(bar);foo()
;[1,2,3].forEach(bar)The advantage is that prefixes are easier to notice since you decide to never start a line with
(or [without a semicolon.Limited rule
Another standard argument for semicolons is related to AIS and restricted rules. For example, if you have a\nright after the token return, throw, break, continue, or ++, or --postfix form (for example, x++\nor y--\n), then these things will end expression - without exception.//ок
return 7
//вероятно, ошибка
return
7\nwith “ok, that's all”, because termination is returnalways sufficient only to line feed. Aligning the most important tokens on the left side of the screen makes them clearly easier for people to quickly analyze. Piles of quick reading studies and eye movements claim that missing a token on the right is more likely to be overlooked than a missing token on the left. So - I repeat - move less important things to the right, and put more important things on the left.
So which style is better?
To the extent that the “best style” exists objectively, it seems to me that the “minimum of semicolon / comma first” style is slightly better; for two reasons: because this style is better readable and because it encourages developers to better understand the language they use.I can guarantee that, no matter how little it worries you, your JS code worries me less than you care about mine. This is not an article where I try to convince you to write code in my style. Everyone must decide what is the policy of wearing pants in his house .
As a manifestation of goodwill ...
Good reasons to put semicolons
Reasons for overusing semicolons are aesthetics and politics."I put semicolons in JS, because otherwise it would not be valid C / C ++ / Java / Anything else." If you have to write a lot of Java or C code in a project and want your JS not to stand out too much, then this is a worthy argument. (The Cassis project brings this argument to an absurd conclusion.)
“We do this because we use the linter, and the linter tells it to.” Consistency is important, and linter is one way to achieve code consistency for a group. The task of writing an npm-compatible linter is on my todo list, but not very high.
The worst things to do with semicolons
“They are required because ASI is unreliable.” Oh, come on ??These rules go back to the dawn of JS, to the late 90s. They are not new, and my opinion is that there is no forgiveness to anyone who calls himself a professional in JS and does not understand the rule of terminating expressions. It is frankly irresponsible for the leaders of the JS community to continue to spread obscurity instead of understanding.
Moreover, the typical place where AIS attacks stealthily is limited rules. Adding semicolons in each line will not force you to
return\nfooreturn anything other than undefined. The problem is that you are using line feeds and not that you are not putting semicolons . The only way foreverprevent errors with limited rules - always use semicolons and never put line breaks . No one offers this. So stop talking about it as if it matters, or suggest redundant semicolons as an alternative to understanding ASI. You must understand ASI in order to be a competent JS programmer, period.
And that leads us to ...
I become all biased and infuriate you (despite the noble attempt to do the opposite)
If you do not understand how expressions are terminated in JS, then you simply do not know JS properly, and should not write professionally in JS without supervision, and definitely should not give advice on how to write it.I think I just insulted you. Very sorry. I know that you know a lot of things about JS - such as DOM, and CSS, and MSIE bugs, and jQuery. You probably spent some time studying closures, and prototypes, and scopes, and activation objects, and even wrote some extensions for V8 or SpiderMonkey. You are not stupid, I'm sure. In fact, you are most likely smarter than me, and you are probably nicer and better looking. I am sure that we have a lot in common, and we could be friends.
But if you do not understandwhat an expression in JS is , in your understanding of what is perhaps the most fundamental aspect of the language - a huge hole.
And this is normal. I do not speak Spanish very well and my C is generally at the beginner level; and I do not call myself an expert in these things, although I know enough to get out in most situations. If I was going to work, which implies a lot of conversations in Spanish or a lot of C, I would like someone to look after me to help avoid some serious mistakes.
Like most things in JS, expression termination rules are not well designed, but they are not very difficult to understand and use. This understanding just takes a little time and effort.
Sit back with hot chocolate and the ECMAScript spec some Saturday night. Practice it. Play with the test programs. This is a good pastime.
Or do not do this if you do not want to. This is your life. Surely you have better classes.
Just stop making authoritative statements like "end all lines with semicolons to be safe." This is not safer and not safer.
Addendum 1: Leaders
So, Mr.-ironing-against-wool, who are these “leaders” you are talking about? Why don't you name names?
Because there are so many of them, and I do not know them all.
If you wrote on JS for a while, and give advice or lead someone with less experience, then I will contact you. Being a leader is a responsibility. Take this seriously. Do not spread the lie. Be an expert, or admit that you are not. But do not drive this car without a license.
Addendum 2: Adherents of Literacy Programming
(Translator's note: literary programming is meant)But in English we put punctuation marks at the end, not at the beginning.
JavaScript is not English. We also do not denote possession (or the object-verb relationship) with a dot in English. There are no object literals in English, and we indent only the first line of a paragraph, and not all sentences.
This is such a stupid argument that I have no choice but to fall in love with him.
I began to insult you, but you won my heart, Adept of Literate Programming. From now on, I will put line feeds only at the end of functions, not in the middle, and indent on the first line of each of them.
Supplement 3: Pedantry
What do you get into my code? What are you pedant galleries?
Write the code as you want. I don't care a bit.
Just please don't lie to people. That is all I ask. This is just a little courtesy. This is not difficult. Just tell the truth instead of lying - that’s what I’m talking about.
(from the translator: as a translator, I want to express my gratitude for the help with the translation and proof-reading to my beloved woman - philologist)