相关疑难解决方法(0)

好吧,首先我应该问一下这是否依赖于浏览器.

我已经读过,如果找到一个无效的令牌,但代码段在该无效令牌之前有效,则在令牌之前插入分号(如果前面有换行符).

但是,由分号插入引起的错误引用的常见示例是:

return
  _a+b;

..它似乎不遵循这个规则,因为_a将是一个有效的标记.

另一方面,分解调用链按预期工作:

$('#myButton')
  .click(function(){alert("Hello!")});

有没有人对规则有更深入的描述？

从历史上看,我喜欢打断表达式,以便在续行中显示"它明显不完整"的偏见:

var something = foo + bar
    + baz(mumble);

这种态度来自于使用分号来终止表达式的语言.由于没有分号,第一行显然已经不完整了,所以最好让读者清楚第二行不完整.

替代方案是:

var something = foo + bar +
    baz(mumble);

这对我来说不是那么好.现在告诉它baz(mumble);不是独立的唯一方法(缩进除了)是扫描你的眼睛到前一行的末尾. (这可能是长的,因为你需要首先打破它.)

但是在奇怪的JavaScript领域,我开始看到人们将代码从看起来像第一种形式的东西改为第二种形式,并警告"自动分号插入".它肯定会引起一些令人惊讶的行为.当我把"学习自动分号插入是什么以及我是否应该这样做"放入我的无限任务队列时,并不是真的想深入研究那个切线.

当我确实调查它时,我发现自己半确定......但不确定......我对它的使用方式没有危险.似乎问题来自于我是否已经停止了+事故并写道:

var something = foo + bar
    baz(mumble);

...然后JavaScript会foo + bar为您插入分号,因为这两行都是完整的表达式.我推断,或许那些其他JavaScript程序员认为偏向"明显有意不完整"的位到最后一行是更好的,因为它指出了分号不在的位置.

然而,如果我已经正确地阐述了我的前提,那么我正在以一种随后的线条"明显不完整"的方式塑造我的虚线.如果情况并非如此,那么我首先不会认为我的方式是优势.

我是否正确,我的方式不是我描述如何使用线延续的条件的风险？是否有任何"看似不完整"的表达陷阱实际上以令人惊讶的方式完成？

为了提供一个"以令人惊讶的方式完成"的例子,考虑是否+ 1;可以将其解释为在一条线上只是正面的.它似乎可以:

但是jsfiddle给出了6个:

var x = 3 + 2
+ 1;
alert(x)

也许这只是控制台中的一个怪癖,但它让我担心我的"只要第二行不是完全表达的解释就可以了".