Визначення змінної JavaScript: Коми проти крапки з комою

Які відмінності та / або переваги, якщо такі є, використання коми при оголошенні групи змінних, а не крапки з комою.

Наприклад:

var foo = 'bar', bar = 'foo';

проти

var foo = 'bar';
var bar = 'foo';

Я знаю, що якщо ви вказали varключове слово для першої змінної в першому прикладі, воно зберігатиметься у всіх змінних, тому вони обидва дають однаковий кінцевий результат щодо області дії. Це лише особисті уподобання, чи є користь від продуктивності робити це так чи інакше?

Немає переваг у виконанні, це лише питання особистого вибору та стилю.

Перша версія - просто більш стисла.

Оновлення:

Що стосується обсягу даних, що надходять по дроту, то, звичайно, менше, тим краще, однак вам знадобиться безліч видалених varдекларацій, щоб побачити реальний вплив.

Мініфікація була згадана як перший приклад, який допоможе покращити мінімізацію, однак, як зазначає Даніель Вассалло в коментарях, хороший мініфікатор все одно автоматично зробить це за вас, тому в цьому відношенні ніякого впливу.

Після прочитання Крокфорда та інших, я почав зв’язувати свої змінні виключно комами. Потім пізніше мене справді дратував налагоджувач Chrome DevTools, який не зупинявся б на визначеннях змінних з комою. Для налагоджувача визначення змінних, прив’язані комами, є єдиним оператором, тоді як кілька операторів var - це кілька операторів, на яких налагоджувач може зупинитися. Тому я повернувся з:

var a = doSomethingA,
    b = doSomethignB,
    c = doSomethingC;

Кому:

var a = doSomethingA;
var b = doSomethignB;
var c = doSomethingC;

На даний момент я вважаю другий варіант набагато чистішим, не кажучи вже про його перевагу у вирішенні проблеми налагоджувача.

Аргумент "менше коду по дроту" не є переконливим, оскільки існують мініфайлери.

Я віддаю перевагу var-per-variableпозначенню:

var a = 2
var b = 3

оскільки інші comma-instead-of-another-varпозначення мають ці три недоліки:

1. Важко підтримувати
Розгляньте цей код:

var a = 1,
    b = mogrify(2),
    c = 3

Але ей, що робить могрифі? Давайте надрукуємо b, щоб з’ясувати:

var a = 1,
    b = mogrify(2),
    console.log(b)
    c = 3

ламає речі

2. Важко читається

Var у початковій лінії чітко повідомляє, що буде ініційована нова змінна.

var get_all_unicorn_promise = db.get_all_unicorns((unicorn) => {
        unicorn.legs.map((leg) => {
            leg.log('yes')
        })
    }).sort(),
    c = 3

Що, блін, там робиться c = 3правильно?

3. Не узгоджується

Розглянемо це:

var a = 1,
    b = 2,
    c = 3

З var-per-variableкожною декларацією дотримуйтесь однакової структури. Сcomma-instead-of-another-var першою змінна оголошується не так, як інші. Якщо ви вирішите, скажімо, перемістити першу змінну всередину циклу for, вам доведеться додати var до середини оголошень

Окрім переваги, здається, що більшість відомих проектів використовують var-per-variableпозначення

Я згоден з іншими відповідачами, що це головним чином питання особистого стилю. Але щоб залучити до дискусії "авторитетну" думку, ось що говорить Дуглас Крокфорд на веб-сайті популярного інструменту JSLint :

Але оскільки JavaScript не має області блоків, розумніше оголосити всі змінні функції у верхній частині функції. Рекомендується використовувати один оператор var для кожної функції. Це можна застосувати за допомогою onevarопції.

Як зазначали інші, це перевага стилю. JSLint може сказати вам мати лише одинvar функцію (якщо ви використовуєте "Хороші частини"). Таким чином, якщо ви використовуєте JSLint для перевірки свого коду (непогана ідея, IMHO), ви в кінцевому підсумку використовуєте перший формат більше, ніж останній.

З іншого боку, той же автор, Дуглас Крокфорд , каже, що слід розміщувати кожну змінну у своєму рядку у своїх правилах кодування . Тож, можливо, ви захочете зняти прапорець "Усі varна функцію" в JSLint, якщо ви ним користуєтеся. ;-)

Я не думаю, що є якась помітна різниця, що стосується мене, це лише особисті переваги.

Я ненавиджу мати кілька оголошень var, тому я зазвичай роблю:

var 
   one
  ,two
  ,three
  ,four
;

Оскільки він коротший і, можливо, більш читабельний, на нього немає varшуму.

Оскільки я не бачу жодних посилань на нього, ось посилання на специфікацію ECMA-262, яка є базовою специфікацією для JavaScript. Граматика на цій сторінці говорить:

12.2 Variable Statement

Syntax

  VariableStatement :
    var VariableDeclarationList ;

  VariableDeclarationList :
    VariableDeclaration
    VariableDeclarationList , VariableDeclaration

  VariableDeclarationListNoIn :
    VariableDeclarationNoIn
    VariableDeclarationListNoIn , VariableDeclarationNoIn

  VariableDeclaration :
    Identifier Initialiseropt

  VariableDeclarationNoIn :
    Identifier InitialiserNoInopt

  Initialiser :
    = AssignmentExpression
  InitialiserNoIn :
    = AssignmentExpressionNoIn

Що ви можете зрозуміти з цього, використовуючи коми чи ні, не має значення. У будь-якому випадку, це закінчується аналізом як a VariableDeclarationі трактується точно так само. Не повинно бути різниці в тому, як механізм сценаріїв обробляє ці два оголошення. Єдиними відмінностями будуть ті, про які вже говорилося в інших відповідях, - економія більше місця та практично незмірна різниця у кількості часу, необхідного для застосування граматики для пошуку всього, VariableDeclarationsколи сценарій компілюється.

Перший зберігає кілька символів - отже, є дуже невелика економія з точки зору розміру файлу JS і, отже, споживання пропускної здатності. Єдиний раз, коли це стане помітним, це буде в крайніх випадках.

Я віддаю перевагу другій версії (кожна має свою var). Я думаю, що це тому, що я походжу з мови C ++. У C ++ ви можете оголосити змінні, як це робите у своєму першому прикладі, але на це не дивляться (це легко призводить до помилок, коли ви намагаєтеся створити вказівники таким чином).

Якщо ви зменшуєте свій javascript, є досить велика користь:

var one, two, three, four;

стає

var a, b, c, d;

Де як

var one;
var two;
var three;
var four;

стає

var a;
var b;
var c;
var d;

Це додаткові три екземпляри var, які з часом можуть складатися.

Див. Серію статей "A List Apart" "Краще зменшення якості Javascript" Частина 1 та Частина 2