Ответ 1

Если у вас есть дополнительная запятая в конце последней строки, она будет работать в некоторых браузерах , но не во всех браузерах. Сделать ошибку сложнее обнаружить, чем добавочную запятую в начале (что не удается во всех браузерах). И большинство разработчиков предпочитают сразу же видеть ошибку (чтобы они могли ее исправить), вместо того, чтобы рисковать проблемой производства, чтобы непреднамеренно не поддерживать некоторые браузеры. Особенно, если решение так же просто, как удаление запятой.

Плюс, имея запятую в начале строки, упростите добавить строку в конце, и вам нужно будет коснуться только этой строки (вы не нужно будет добавлять запятую в строку до). Это важно, если вы используете контроль версий (например, diff, annotate, bisect). Кто-то может утверждать, что добавление строки в начале массива или объекта потребует такой же дополнительной работы касания двух строк (если вы используете запятую в начале), но, по моему опыту, вставка строки в начале гораздо менее вероятно, что вставляя строку в конец.

Ответ 2

Это потому, что запятая относится к следующей инструкции new line, а не предыдущей. (Поскольку @Dave Newton утверждает это в своем комментарии ниже: псевдо-BNF будет foo [, foo] * - ish)

Например:

Если у вас есть это:

a,
b,
c

Если вам нужно удалить c, вам нужно удалить две вещи: de c и запятую в предыдущей строке. Если вы это сделаете:

a
,b
,c

теперь вам нужно удалить строку c. Это имеет большее значение, потому что запятая за b в первом примере нужна только из-за c. Однако это выглядит хуже. Это компромисс между ремонтопригодностью вашего кода и тем, как он выглядит.

Ответ 3

Я думаю, что это сделало так, чтобы было легче обнаружить пропущенную запятую.

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

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

Ответ 4

Уже много замечательных ответов. Позвольте мне дать вам свой собственный, чтобы сделать все как можно яснее.

Я лично называю этот способ написания кода "Стиль Haskel", так как это общий стиль для использования в 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 из одного из моих проектов:

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" использует макет стиля столбца. Этот стиль столбца делает ваш код более удобочитаемым. Фактически, это делает ваш код настолько читабельнее, что вы используете его все время. Представьте, что вы пишете код без вкладок или пробелов!

Используя преимущества стиля столбцов, имена переменных, типы и т.д. легче читать. Объединив переменные с помощью префикса, наш будущий читатель легко найдет то, что ищет, не используя расширенный поисковый запрос.

Легко документировать

Макет стиля столбцов имеет больше преимуществ. Сгруппировав наш код, мы можем добавить столбец, зарезервированный для комментариев. Теперь вы можете прочитать свой код, даже не требуя выделения цвета, а добавление информации в ваш комментарий так же просто, как найти правильный столбец и его изменить. Кроме того, этот стиль, похожий на столбец, документирующий ваш код, в значительной степени зависит от того, что вы получаете после использования генератора документации, такого как 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 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; DR

Этот стиль размещения запятой "Стиль Haskell" имеет несколько преимуществ:

• Легко читаемый
• Легко документировать
• Легко заметить ошибки.
• Легко масштабируемый

Ответ 5

Легче просто взглянуть на ваш код, чтобы убедиться, что у вас есть запятая, где это необходимо. Если вам нужно было отсканировать конец каждой строки кода, пропущенные запятые не просто выскочили бы, как они, когда они выстроились в левой части.

Ответ 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

Ответ 7

Это один из способов убедиться, что вы не забыли запятую при добавлении нового элемента в коллекцию и не случайно оставляете конечную запятую в коллекциях.

Поместив его на новую строку, он визуально очевиден.

Мне все равно, но я понимаю, почему люди будут.

Ответ 8

Может быть, потому, что удаление или добавление строки и ее запятых проще во втором примере

Ответ 9

Возможно, вы смотрите на сгенерированный код, например, при написании цикла для генерации оператора выбора 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

Это функционально эквивалентно, но тогда идентификатор не появляется там, где я обычно этого хочу.