Definicja zmiennej JavaScript: przecinki a średniki

Jakie są różnice i / lub zalety używania przecinków podczas deklarowania grupy zmiennych zamiast średników.

Na przykład:

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

przeciw

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

Wiem, że jeśli określisz varsłowo kluczowe na pierwszej zmiennej w pierwszym przykładzie, będzie ono obowiązywać we wszystkich zmiennych, więc obie dają ten sam wynik końcowy pod względem zakresu. Czy to tylko osobiste preferencje, czy też jest to korzystne dla wydajności?

Brak korzyści w zakresie wydajności, tylko kwestia osobistego wyboru i stylu.

Pierwsza wersja jest po prostu bardziej zwięzła.

Aktualizacja:

Jeśli chodzi o ilość danych przesyłanych przez sieć, oczywiście mniej znaczy lepiej, jednak varaby zobaczyć rzeczywisty wpływ, potrzebowałbyś ogromnej ilości usuniętych deklaracji.

Minifikacja została wymieniona jako coś, w czym pierwszy przykład pomoże w lepszej minifikacji, jednak, jak Daniel Vassallo wskazuje w komentarzach, dobry minifier i tak zrobi to automatycznie, więc pod tym względem nie ma żadnego wpływu.

Po przeczytaniu Crockforda i innych zacząłem łączyć moje zmienne wyłącznie z przecinkami. Później naprawdę zirytował mnie debugger Chrome DevTools, który nie zatrzymywał się na definicjach zmiennych przecinkiem. W przypadku debugera definicje zmiennych połączone przecinkami to pojedyncza instrukcja, podczas gdy wiele instrukcji var to wiele instrukcji, na których debugger może się zatrzymać. Dlatego wróciłem z:

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

Do:

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

Do tej pory uważam, że drugi wariant jest znacznie czystszy, nie wspominając o jego zaletach w rozwiązaniu problemu z debugerem.

Argument „mniej kodu w sieci” nie jest przekonujący, ponieważ istnieją pomniejszacze.

Wolę var-per-variablenotację:

var a = 2
var b = 3

ponieważ druga comma-instead-of-another-varnotacja ma te trzy wady:

1. Trudne w utrzymaniu
Rozważ ten kod:

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

Ale hej, co robi mogrify? Wydrukujmy b, aby dowiedzieć się:

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

niszczy rzeczy

2. Trudne do odczytania

Zmienna na początku linii jasno informuje, że zostanie zainicjowana nowa zmienna.

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

Co tam do cholery c = 3robi, prawda?

3. Niespójne

Rozważ to:

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

Przy var-per-variablekażdym zgłoszeniu zgodnie z tą samą strukturę. Z comma-instead-of-another-varpierwszą zmienną deklaruje się inaczej niż pozostałe. Jeśli zdecydujesz się, powiedzmy, przenieść pierwszą zmienną wewnątrz cyklu for, będziesz musiał dodać zmienną do środka deklaracji

Poza preferencjami wydaje się, że większość znaczących projektów używa var-per-variablenotacji

Zgadzam się z innymi respondentami, że jest to głównie kwestia osobistego stylu. Aby jednak wnieść do dyskusji opinię „autorytatywną”, oto co mówi Douglas Crockford na stronie internetowej popularnego narzędzia JSLint :

Ponieważ jednak JavaScript nie ma zakresu blokowego, rozsądniej jest zadeklarować wszystkie zmienne funkcji na początku funkcji. Zaleca się użycie jednej instrukcji var na funkcję. Można to wymusić za pomocą onevaropcji.

Jak zauważyli inni, jest to preferencja stylu. JSLint może powiedzieć, że masz tylko jedną varna funkcję (jeśli używasz „dobrych części”). Tak więc, jeśli używasz JSLint do sprawdzenia swojego kodu (niezły pomysł, IMHO), skończysz używać pierwszego formatu częściej niż drugiego.

Z drugiej strony ten sam autor, Douglas Crockford , mówi, że każdą zmienną należy umieścić w osobnym wierszu w swoich konwencjach kodowania . Dlatego możesz odznaczyć pole wyboru „Wszystkie po jednym varna funkcję” w JSLint, jeśli go używasz. ;-)

Nie sądzę, żeby była jakaś zauważalna różnica, jeśli o mnie chodzi, to tylko osobiste preferencje.

Nienawidzę mieć wielu deklaracji var, więc zwykle robię:

var 
   one
  ,two
  ,three
  ,four
;

Ponieważ jest krótszy i prawdopodobnie bardziej czytelny, nie ma varhałasu.

Ponieważ nie widzę żadnych odniesień do niego, oto link do specyfikacji ECMA-262, która jest podstawową specyfikacją dla JavaScript. Gramatyka z tej strony mówi:

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

To, co możesz z tego wyciągnąć, to użycie przecinków lub nie ma to znaczenia. Tak czy inaczej, kończy się parsowaniem jako a VariableDeclarationi jest traktowany dokładnie tak samo. Nie powinno być różnicy w sposobie, w jaki silnik skryptów traktuje te dwie deklaracje. Jedynymi różnicami byłyby te, które zostały już wspomniane w innych odpowiedziach - oszczędność miejsca i praktycznie niewymierne różnice w ilości czasu potrzebnego na zastosowanie gramatyki, aby znaleźć wszystko, VariableDeclarationskiedy skrypt jest kompilowany.

Pierwsza oszczędza kilka znaków - więc jest bardzo mała oszczędność pod względem rozmiaru pliku JS, a tym samym zużycia przepustowości. Jedyny moment, w którym stałoby się to zauważalne, miałby miejsce w skrajnych przypadkach.

Wolę drugą wersję (każda ma swoją var). Myślę, że to dlatego, że wywodzę się z C ++. W C ++ możesz deklarować zmienne, tak jak w pierwszym przykładzie, ale jest to źle widziane (łatwo prowadzi do błędów, gdy próbujesz utworzyć wskaźniki w ten sposób).

Jeśli minimalizujesz swój javascript, masz dość dużą korzyść:

var one, two, three, four;

staje się

var a, b, c, d;

Natomiast

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

staje się

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

To dodatkowe trzy przypadki var, które mogą się sumować w czasie.

Zobacz serię artykułów „Lista od siebie” „Lepsza minifikacja JavaScript” część 1 i część 2