【问题标题】：Why do lots of programmers move commas to the next line? [closed]为什么很多程序员把逗号移到下一行？ [关闭]
【发布时间】：2012-05-16 01:15:46
【问题描述】：

请告诉我，以下风格的神圣力量是什么：

var javascript = new Language(
  'Brendan Eich'
, new Date(1995, 0, 1)
, ['C', 'Java', 'Scheme']
);

为什么很多程序员都使用这种风格？它有什么好处？例如，

var javascript = new Language(
  'Brendan Eich',
  new Date(1995, 0, 1),
  ['C', 'Java', 'Scheme']
);

我比以前更喜欢。谢谢。

【问题讨论】：

这样的问题可能更适合programmers.stackexchange.com
由于分号插入，在 js 中相当肯定逗号在行尾更好。
我将 ASI 称为“Asinine 分号插入”

标签： javascript

【解决方案1】：

已经有很多很棒的答案了。请允许我给你我自己的，让事情尽可能清楚。

我个人将这种编写代码的方式称为“Haskell 风格”，因为它是 Haskell 中常用的一种风格。让我先给你一个 Haskell 的例子：

data Settings = -- The user settings
    { has_sound     :: Bool   -- Determines if the user has sound
    , has_power     :: Bool   -- Determines if the user has electricity
    , has_graphics  :: Bool   -- Determines if the user has graphics
    , user_name     :: String -- The name of the user
    , user_password :: String -- The hashed password of the user
    , user_email    :: Email  -- The email address of the user
    , stylesheet    :: Style  -- The stylesheet to use
    }

还有来自我的一个项目的 Javascript sn-p：

var events // Holds the events to generate a event handler for.
  , var2   // Quick description for var2.
  , var3   // Quick description for var3.
  , ...    // ...
  ;
events = // Event handlers will be generated for the following events:
    [ "onmousedown"  // Works outside of the window element
    , "onmouseup"    // Works outside of the window element
    , "onmousemove"  // Works outside of the window element
    , "onmousewheel" // This will handle DOMMouseScroll aswell
    ];

“Haskell 风格”的好处

易于阅读

'Haskell style' 利用了列样式布局。这种列样式使您的代码更具可读性。事实上，它使您的代码更具可读性，以至于您一直都在使用它。想象一下编写没有制表符或前导空格的代码！

通过利用列样式布局，变量名称、类型等也更易于阅读。通过按前缀对变量进行分组，我们未来的读者将很容易找到他正在寻找的内容，而无需使用高级搜索查询。

易于记录

列式布局更有优势。通过对我们的代码进行分组，我们可以添加一个为 cmets 保留的列。现在您可以阅读您的代码，甚至不需要颜色突出显示，并且向您的评论添加信息就像找到正确的列并修改它一样简单。此外，这种列式记录代码的方式几乎是使用 Doxygen 等文档生成器后得到的，无需使用此类工具。

容易发现错误

使用这种编码风格，注意到缺少的逗号是小菜一碟。只需寻找不以它开头的行！另一方面，我们在行尾有逗号。我们错过了一个？不，因为它是最后一个元素，或者因为表达式在下一行继续。查找列表中的第一个元素非常简单。在处理长行时，第一个元素很容易被忽略，但是通过将第一个元素放在它自己的行上并在其前面放置 [ 或 { 而不是 , ，很容易发现。

易于扩展

您可能会说“但是一旦表达式变大，这种布局样式将变得无法处理！”，这是完全正确的，但这对于您的其余代码有什么不同吗？我认为通过使用列样式，您至少可以保持代码的可读性，从长远来看，这比您可能不得不将其放入列布局中的努力更有价值。

一个例子！

var scalable = // This is a example variable
    [
        [ new MyObject // This is how I would style Object Allocation
              ( "11"
              , "This is the first element"
              , function // This is a very secret function...
                  ( secret   // ..with secret..
                  , variable // ..variable..
                  , names    // ..names!
                  )
                {
                    // <-- Use spaces, not tabs :)
                }
              )
        , "12"
        ]
    ,
        [ { id:   21                          // Where's 20?
          , name: "This is the third element" // It sure is
          , func: function() { /* My body feels empty :c */ }
          }
        , "22" // Notice how 21 is a integer, not a string. Sneaky!
        ]
    ];

TL;博士

这种放置逗号的风格，“Haskell 风格”，有几个优点：

易于阅读
易于记录
容易发现错误
易于扩展

【讨论】：

您可以使用不带前导逗号的列间距，使前导或尾随同样易于记录/评论。而且我不同意“更容易阅读”，不管有多少 Haskeler 这么说，因为它需要在第一件有价值的东西之前有“噪音”，这意味着你需要训练你的大脑来“隐藏”噪音扫描代码时，你的大脑总是需要处理它......“最后缺少的逗号”是一件很容易发现和修复的事情，因此清洁和更易于扫描似乎值得。
那些逗号看起来像地上的烟头

【解决方案2】：

如果您在最后一行的末尾有一个额外的逗号，它可以在某些浏览器中工作但不是在所有浏览器中。使错误比开头的额外逗号更难检测（在所有浏览器上都失败）。大多数开发人员更愿意立即看到错误（以便他们可以修复它），而不是冒着因无意中不支持某些浏览器而出现生产问题的风险。特别是如果解决方案就像删除逗号一样简单。

另外，在行的开头有逗号，使在末尾添加一行更简单，您将必须只触摸该行（您不需要在前面的行中添加逗号）。如果您使用版本控制（例如 diff、annotate、bisect），这很重要。有人可能会争辩说，在数组或对象的开头添加一行将需要与两行相同的额外工作（如果您在开头使用逗号），但根据我的经验，在开头插入一行的可能性要小得多在末尾插入一行。

【讨论】：

如果您在第一行的开头有一个额外的逗号，它在几乎所有浏览器中都会失败。只是说。
我同意这个观点。但是当人们在var 部分中使用该规则时也很奇怪。在这种情况下，我们应该删除要添加变量的每一行的分号，或者使用 ASI 这不好，恕我直言。
@cHao 当然，但我更喜欢第一行的错误，它很容易在任何浏览器中检测到，应该在开发人员进行的测试中发现，而不是最后一行的错误，可以隐藏一段时间，并在修复成本更高时在生产中被发现。
这可能是旧的，但我怀疑每个人都会同意在开头插入一行“不太可能”。就我个人而言，我认为在列表的开头插入一行与在末尾、中间或任何其他点一样可能。这有点取决于列表中的内容，不是吗？即使对于在必要时跨越多行的函数签名（eww），我也经常在开头和结尾插入参数，这取决于语义上哪个更有意义。
@kevlarr 很公平。我已经编辑了我的答案。感谢您的反馈。

【解决方案3】：

这是因为逗号属于 ~~new line~~ 下一条语句，而不是前一条。（正如@Dave Newton 在下面的评论中所说：伪 BNF 将是 foo [, foo]*-ish）

例如：

如果你有这个：

a,
b,
c

如果您需要删除c，那么您需要删除两件事：de c 和上一行的逗号。如果你这样做：

a
,b
,c

现在您只需要删除 ,c 行。这种方式更有意义，因为在第一个示例中，b 后面的逗号只是因为c 而需要。不过这样看起来确实更糟。这是代码的可维护性和外观之间的权衡。

【讨论】：

除了您的个人意见之外还有什么争论吗？
我稍微解释了一下。希望对你有帮助
@mata 从语法上讲，伪 BNF 将是 foo [, foo]*-ish。我认为这个论点是逗号与以下陈述相关联，而不是最初的陈述。这并没有解决“新行”的问题，但 IMO 逗号与关注 foos 更紧密相关。
@koenp：现在，如果您删除 a 行，您就会遇到问题。（您不仅需要删除该行，还需要删除它后面的逗号。）您并没有减少问题的数量，只是将它们随机排列。
这不是不理解重点，而是最初的答案是“因为。就是这样。” （有点）。不过现在好多了（尽管可能有争议）。

【解决方案4】：

我认为这样做是为了更容易发现遗漏的逗号。

var something = 0,
    foo = "a string",
    somethingElse = []
    bar;

var something = 0
  , foo = "a string"
    somethingElse = []
  , bar;

【讨论】：

【解决方案5】：

只需查看您的代码即可更轻松地验证您在需要的地方是否有逗号。如果您必须扫描每行代码的末尾，那么缺少的逗号不会像它们在左侧排列时那样跳出来。

【讨论】：

所以您以牺牲可读性为代价来提高可维护性...？看起来你在这里并没有真正获得任何东西。
我认为，如果我们有超过 80 个符号的行 - 有问题:) 这不是降低可读性的重点。但是你的观点很有趣。谢谢！

【解决方案6】：

这为不接受尾随逗号的语言提供了一些保护，以免意外引入尾随逗号的语法错误

在 SQL 中，尾随逗号会导致语法错误。在 JavaScript 中，大多数地方都会接受它，但在某些 Internet Explorer 版本中会失败并出现一个隐秘的错误。

JS 适用于大多数浏览器，但在某些浏览器中失败

var thing = {
 a: 1,
 b: 2,
 // trailing comma
 c: 3,
};

SQL 中的语法错误

SELECT
  col1,
  col2,
  -- Syntax error in SQL
  col3,
FROM table

【讨论】：

它是 .js，而不是 SQL。还有像jslint/jshint 这样的工具也存在......而且它们显示了额外的逗号。
@InviS 是的，这些工具确实存在。不是每个人都使用它们。事实上，相当多的人不使用它们。倾向于采用逗号前风格的人倾向于跨多种语言这样做，这就是我指出 SQL 的原因。
:) 可能，但我只在 js 专家编写的示例中看到过这种风格 :) 此外，这种风格经常在 nodejs 上的 npm-packages 中使用。
@InviS 专家与否有什么关系？它是一种编码标准，通常由团队或项目的成员商定。这完全是任意的。
样式和用例是其中的一部分。我认为新手不可能有完美的代码编写风格，但专家可以。

【解决方案7】：

这是确保您在向集合中添加新项目时不会忘记逗号的一种方法，并且不会意外地留在集合中的尾随逗号上。

通过将其放在新行上，它在视觉上很明显。

我不在乎，但我明白人们为什么会这样做。

【讨论】：

正如我在上面指出的那样，当您使用ASI 时，这很简单......

【解决方案8】：

您可能正在查看生成的代码，例如，在编写循环以生成 SQL 选择语句时，有时我会这样写：

sql =  "SELECT";
sql += "  table.id"; // or some field that will always be in the query
for (var i = 0; i < 10; i++;) {
  sql += ",  table.field" + i; 
}
sql += "FROM table" // etc

而不是在末尾添加逗号，然后在循环的最后一次迭代或执行以下条件时省略它：

sql =  "SELECT";
for (var i = 0; i < 10; i++;) {
  sql += "  table.field" + i + ","; 
}
sql += "  table.id";
sql += "FROM table" // etc

这在功能上是等效的，但是 ID 并没有出现在我通常想要的位置。

【讨论】：

不，这是一些关于 JS 的文章中的一个例子。

【解决方案9】：

可能是因为在第二个示例中删除或添加行及其逗号更简单

【讨论】：