下一行继续操作时会有分号插入的危险吗? [英] Are there semicolon insertion dangers with continuing operators on next line?
问题描述
从历史上看，我喜欢破坏表达式，以便在连续的行中显示明显不完整"的偏见:
Historically, I like to break expressions so that the "it's clearly incomplete" bias is shown on the continued line:
var something = foo + bar
+ baz(mumble);
这种态度源于使用需要分号终止表达式的语言进行工作.由于没有分号，第一行显然已经不完整，因此最好让读者清楚第二行还不完整.
This is an attitude that comes from working in languages which need semicolons to terminate expressions. The first line is already obviously incomplete due to no-semicolon, so it's better to make it clear to the reader that the second line is not complete.
替代方法是:
var something = foo + bar +
baz(mumble);
那对我不好.现在，唯一说明baz(mumble);不是独立的(缩进)的方法是将眼睛扫描到上一行的末尾. *(大概很长，因为您需要首先将其断开.)*
That's not as good for me. Now the only way to tell that baz(mumble); isn't standalone (indentation aside) is to scan your eyes to the end of the previous line. * (Which is presumably long, as you needed to break it in the first place.)*
但是在奇异的JavaScript领域，我开始看到人们将代码从看起来像第一种形式的内容更改为第二种形式，并警告自动分号插入".它肯定会导致一些令人惊讶的行为.在我将了解什么是自动分号插入以及是否也应该这样做" 放入我的无限任务队列时，我并不想真的去研究这个切线.
But in bizarro JavaScript land, I started seeing people changing code from things that looked like the first form to the second, and warning about "automatic semicolon insertion". It certainly causes some surprising behaviors. Not really wanting to delve into that tangent at the time I put "learn what automatic semicolon insertion is and whether I should be doing that too" into my infinite task queue.
当我研究它时，我发现自己是半确定的……但不确定……我的使用方式没有危险.看来问题出在我偶然放弃+并写成:
When I did look into it, I found myself semi-sure... but not certain... that there aren't dangers with how I use it. It seems the problems would come from if I had left off the + on accident and written:
var something = foo + bar
baz(mumble);
...然后JavaScript会为您在foo + bar之后插入一个分号，这似乎是因为这两行都是完整的表达式.我推断出其他JavaScript程序员可能认为将明显有意不完整"的部分偏向要继续的行的结尾会更好，因为它可以精确地指出分号不在的位置 .
...then JavaScript inserts a semicolon after foo + bar for you, seemingly because both lines stand alone as complete expressions. I deduced perhaps those other JavaScript programmers thought biasing the "clearly intentionally incomplete" bit to the end of the line-to-be-continued was better, because it pinpointed the location where the semicolon wasn't.
但是，如果我正确地陈述了前提，那么我将以不连续的线条显然是不完整的"的方式来设置虚线的样式.如果不是这种情况，那么我一开始就不会考虑自己的方式.
Yet if I have stated my premise correctly, I am styling my broken lines in a way that the ensuing lines are "obviously incomplete". If that weren't the case then I wouldn't consider my way an advantage in the first place.
我是否正确，我对我描述的如何使用行延续的条件没有风险?是否有以令人惊讶的方式完成的看起来不完整"的表达陷阱?
要提供以令人惊讶的方式完成"的示例，请考虑将+ 1;本身是否可以解释为仅是肯定的一行.看来可以做到:
To offer an example of "complete in surprising ways", consider if + 1; could be interpreted as just positive one on a line by itself. Which it seems it can:
但是JSFiddle为此返回了6:
But JSFiddle gives back 6 for this:
var x = 3 + 2
+ 1;
alert(x)
也许这只是控制台中的一个古怪之处，但这使我担心我的只要第二行不能单独作为完整的表达方式就可以了" 解释.
Maybe that's just a quirk in the console, but it causes me to worry about my "it's okay so long as the second line doesn't stand alone as complete expression" interpretation.
推荐答案
如果您采用语法上有效的行并使用换行符对其进行标点，则自动分号插入将不适用(在狭窄情况下除外) return，throw和其他很少的语句，如下所示).仅当绝对没有其他方法可以解释代码时，才会发生ASI.当然，有一种方法可以将多行代码解释为单个语句，因为它可以作为一行有效.简而言之，ASI通常是解析器尝试理解程序的最后手段.
If you take some syntactically valid line and punctuate it with line breaks, automatic semicolon insertion will not apply (except in the narrow case of return, throw and very few other statements, listed below). ASI only occurs when there is absolutely no other way to interpret the code. Certainly, there is a way to interpret your multiline code as a single statement, because it is valid as a single line. In short, ASI is generally a tool of last resort in the parser's attempt to understand the program.
要引用ES5，请参见有关ASI的第一种情况规范出现...
To cite ES5, the first case of ASI detailed in the spec occurs...
- 当从左到右解析程序时，遇到任何语法产生不允许的令牌(称为冒犯令牌) ...
- When, as the program is parsed from left to right, a token (called the offending token) is encountered that is not allowed by any production of the grammar...
但是这种情况自然可以消除，因为在将换行符注入之前，您有一个语法上有效的行.因此，这种ASI情况不适用于您的情况，因为它取决于没有分号而在语法上无效的一段代码.你在这里没有那个.
But that case is naturally eliminated, because you had a grammatically valid line before you injected a newline into it. Thus, this case of ASI cannot apply to your case because it depends upon a span of code that is not syntactically valid without semicolons. You don't have that here.
(其他两种情况也不适用；第二种情况适用于程序的末尾，第三种情况适用于continue，break，return，throw和后缀--运算符.)
(The other two cases don't apply either; the second case applies to the end of a program and the third case applies to continue, break, return, throw, and postfix ++/-- operators.)
人们对ASI的常见问题是当作者有两条希望分开站立的 行时发生的，但是当被理解为一行时，这两行恰好不会引起语法问题.这种情况从两行开始，然后偶然地变成一行.你的情况是相反的:你以一行开始； not 偶然变成了两个.
The common problem people have with ASI occurs when an author has two lines which he expects will stand separately, but those two lines happen to cause no grammatical problem when understood as a single line. That case starts with two lines and they accidentally become one. Your cases is the inverse: you start with one line; it does not accidentally become two.
这篇关于下一行继续操作时会有分号插入的危险吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
