JavaScript之外的任何其他语言在大括号开始位置(同一行和下一行)之间是否有区别？

Question

今天,当我随机阅读O'Reilly书中的JavaScript模式时,我发现了一件有趣的事情(第27页供参考).

在Javascript中,在某些情况下,如果大括号的起始位置不同,则会有所不同.

function test_function1() {
    return
    {
        name: 'rajat'
    };
}

var obj = test_function1();
alert(obj);  //Shows "undefined"

而

function test_function2() {
    return {
        name: 'rajat'
    };
}

var obj = test_function2();
alert(obj); //Shows object

JSfiddle演示

有没有其他语言有这种行为？如果是这样,那么我肯定要改变我的习惯.. :)

我主要关注PHP,C,C++,Java和ruby.

Answer 1

任何不依赖于分号(而是依赖于换行符)来分隔语句的语言都可能允许这样做.考虑Python:

>>> def foo():
...   return
...   { 1: 2 }
... 
>>> def bar():
...   return { 1: 2 }
... 
>>> foo()
>>> bar()
{1: 2}

你可能能够在Visual Basic中构建一个类似的案例,但是我无法弄清楚是怎么回事,因为VB在可能放置值的地方非常严格.但是除非静态分析器抱怨无法访问的代码,否则以下情况应该有效:

Try
    Throw New Exception()
Catch ex As Exception
    Throw ex.GetBaseException()
End Try

' versus

Try
    Throw New Exception()
Catch ex As Exception
    Throw
    ex.GetBaseException()
End Try

从您提到的语言中,Ruby具有相同的属性.PHP,C,C++和Java不仅仅是因为它们将换行符丢弃为空格,并且需要使用分号来分隔语句.

这是Ruby中Python示例的等效代码:

>> def foo
>>   return { 1 => 2 }
>> end
=> nil
>> def bar
>>   return
>>   { 1 => 2 }
>> end
=> nil
>> foo
=> {1=>2}
>> bar
=> nil

Answer 2

;如果找不到,那么JavaScript解释器会在每行的末尾自动添加一个(除了一些例外,这里没有进入它们:).

所以基本上问题不在于大括号的位置(这里代表一个对象文字,而不是大多数语言中的代码块),但是这个小"特征"强迫你的第一个例子return ;=> undefined.您可以查看return ES5规范中的行为.

对于具有类似行为的其他语言,请查看Konrad的答案.

Answer 3

当然可以.谷歌的去编程语言呈现出非常相似的行为(尽管有不同的效果).如上所述:

事实上,正式语言使用分号,就像在C或Java中一样,但它们会自动插入到每个看起来像语句结尾的行的末尾.您不需要自己键入它们.

..snip ...

这种方法可以实现外观整洁,无分号的代码.令人惊讶的是,将if语句等构造的左大括号放在与if相同的行上是很重要的.如果不这样做,有些情况可能无法编译或可能给出错误的结果.语言在某种程度上强制支撑风格.

偷偷地说,我认为Rob Pike只是想借口要求One True Brace Style.

Answer 4

这个问题的答案相当容易.任何具有"自动分号插入"的语言都可能在该行上出现问题.这个问题

return
{
     name: 'rajat'
};

..是js引擎将在return;语句后插入一个分号(因此返回undefined).这个例子是一个很好的理由,总是在右侧打开花括号,也从不在左侧.由于您已经正确注意到,如果同一行中有一个大括号,解释器会注意到并且不能插入分号.

Answer 5

FWIW,JSLint使用该语法报告了几个警告:

$ jslint -stdin
function foo(){
  return
  { x: "y" };
}
^D
(3): lint warning: unexpected end of line; it is ambiguous whether these lines are part of the same statement
  return
........^

(3): lint warning: missing semicolon
  { x: "y" };
..^

(3): lint warning: unreachable code
  { x: "y" };
..^

(3): lint warning: meaningless block; curly braces have no impact
  { x: "y" };
..^

(3): lint warning: use of label
  { x: "y" };
.....^

(3): lint warning: missing semicolon
  { x: "y" };
...........^

(3): lint warning: empty statement or extra semicolon
  { x: "y" };
............^


0 error(s), 7 warning(s)