Ile powinienem używać „let” vs „const” w ES6?

Ostatnio pisałem dużo kodu ES6 dla io.js. Na wolności nie ma zbyt wiele kodu do nauki, więc czuję, że definiuję własne konwencje.

Moje pytanie brzmi, kiedy w użyciu constvs let.

Stosowałem tę zasadę: Jeśli to możliwe, użyj const. Używaj tylko, letjeśli wiesz, że jego wartość musi się zmienić. (Zawsze możesz wrócić i zmienić a constna a, letjeśli później okaże się, że musisz zmienić jego wartość).

Głównym powodem tej reguły jest to, że łatwo ją konsekwentnie stosować. Nie ma szarych obszarów.

Chodzi o to, że kiedy stosuję tę zasadę, w praktyce 95% moich deklaracji to const. I to wydaje mi się dziwne. Jestem tylko przy użyciu letrzeczy jak iw forpętli, lub od czasu do czasu na takie rzeczy jak skumulowane sumy Fibonacciego (który nie pojawia się wiele w życiu). Zaskoczyło mnie to - okazuje się, że 95% „zmiennych” w moim kodzie ES5 do tej pory dotyczyło wartości, które się nie zmieniają. Ale widzenie constcałego mojego kodu wydaje się jakoś źle.

Moje pytanie brzmi: czy można consttak często korzystać? Czy naprawdę powinienem robić takie rzeczy const foo = function () {...};?

A może powinienem zarezerwować constna takie sytuacje, w których kodujesz literał na samym szczycie modułu - na przykład w przypadku wielkich liter const MARGIN_WIDTH = 410;?

Moja odpowiedź tutaj nie jest związana z javascript.

Jako ogólną zasadę w każdym języku, który pozwala mi to zrobić w pół-łatwy sposób, powiedziałbym, że zawsze używaj const / final / readonly / cokolwiek to się nazywa w twoim języku, kiedy tylko jest to możliwe. Powód jest prosty, o wiele łatwiej jest wnioskować o kodzie, gdy nie wiadomo, co można zmienić, a co nie. Oprócz tego w wielu językach można uzyskać pomoc techniczną, która mówi, że robisz coś złego, gdy przypadkowo przypisujesz zmienną, którą zadeklarowałeś jako const.

Cofanie się i zmiana stałej na let jest bardzo proste. A przejście do trybu domyślnego powoduje, że musisz się dwa razy zastanowić. I w wielu przypadkach jest to dobra rzecz.

Ile widziałeś błędów, które powodowały nieoczekiwane zmiany zmiennych? Chyba dużo. Wiem, że większość błędów, które widzę, obejmują nieoczekiwane zmiany stanu. Nie pozbędziesz się tych wszystkich błędów, swobodnie używając const, ale pozbędziesz się ich wszystkich!

Ponadto wiele języków funkcjonalnych ma niezmienne zmienne, w których wszystkie zmienne są domyślnie stałe. Spójrz na przykład na Erlang lub F #. Kodowanie bez przypisania działa idealnie w tych językach i jest jednym z wielu powodów, dla których ludzie kochają programowanie funkcjonalne. Z tych języków można się wiele nauczyć na temat zarządzania stanem, aby zostać lepszym programistą.

A wszystko zaczyna się od bycia wyjątkowo liberalnym z Const! ;) To tylko dwa znaki do napisania w porównaniu do let, więc śmiało i tak dalej const!

Uważaj, ponieważ constklucze obiektów można modyfikować.

Stąd: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const

klucze obiektów nie są chronione

rozważ ten przykład:

const colors = {red: "#f00"}; 
console.log(colors); // { "red": "#f00" }

colors.red = "#00f";
colors.green = "#0f0";
console.log(colors); // { "red": "#00f", "green": "#0f0" }

To samo dotyczy tablic:

const numbers = [1, 2, 3];
console.log(numbers); // [ 1, 2, 3 ]

numbers.push(4);
console.log(numbers); // [ 1, 2, 3, 4 ]

Nie zdecydowałem się całkowicie sam, ale rozważam użycie constwszystkich obiektów nie-tablicowych / innych niż obiektowe i użycia letdla obiektów / tablic.

Nie martw się o to. constjest niesamowitym dodatkiem do JavaScript i polecam używać go we wszystkich miejscach, które ma sens. To sprawia, że ​​kod jest bardziej niezawodny.

Jeśli chodzi o obiekty, constbędzie chronić twoją zmienną przed ponownym przypisaniem, ale jeśli potrzebujesz niezmiennych obiektów, będziesz potrzebować Object.freezemetody, patrz poniżej.

const immutableOject = Object.freeze({immutableProperty: 'foo'});

constochroni tylko przed ponownym przypisaniem, a freezemetoda ochroni wszystkie bezpośrednie właściwości. Jeśli wszystkie zagnieżdżone właściwości również są niezmienne, musisz freezeje rekurencyjnie .

W moim ES6 constnie chodzi o post niezmienności , wyjaśniam, co constdokładnie znaczy zgodnie ze specyfikacją.

W oparciu o te obiektywne fakty, oto moje osobiste preferencje:

[…] Ma sens użycie leti constw następujący sposób w kodzie ES6:

• użyj constdomyślnie
• używaj tylko letwtedy, gdy konieczne jest ponowne wiązanie (tj. dowolna zmiana przypisania)
• ( varnie należy używać w ES6)

Może to być subiektywne, ale faktem jest, że to najbardziej pasuje do intencji specyfikacji.

Ludzie, którzy używają letdomyślnie zwykle traktują constzmienne jako stałe (które niekoniecznie są z założenia!). Dla każdego z nich, ale wolę używać rzeczy zgodnie z ich przeznaczeniem, a nie dla niektórych wymyślonych znaczeń, które ludzie przypisują temu na podstawie nieporozumienia.

Używanie consttylko do stałych jest jak używanie elementu HTML<aside> tylko do zawartości paska bocznego.

Moje osobiste podejście, pomyślane o pomocy w czytaniu i zrozumieniu kodu:

letjest tylko dla zmiennych krótkotrwałych, zdefiniowanych w jednym wierszu i nie zmienianych później. Zasadniczo te zmienne, które są tylko po to, by zmniejszyć ilość pisania. Na przykład:

for (let key in something) {
  /* we could use `something[key]` for this entire block,
     but it would be too much letters and not good for the
     fingers or the eyes, so we use a radically temporary variable
  */
  let value = something[key]
  ...
}

constdla wszystkich nazw znanych jako stałe w całym module. Bez uwzględnienia lokalnych wartości stałych. Na valueprzykład powyższy przykład ma stały zasięg i może być zadeklarowany za pomocą const, ale ponieważ istnieje wiele iteracji i dla każdej z nich istnieje wartość o tej samej nazwie „wartość”, która może skłonić czytelnika do myślenia, że valuezawsze jest to samo. Moduły i funkcje są najlepszym przykładem constzmiennych:

const PouchDB = require('pouchdb')
const instantiateDB = function () {}
const codes = {
  23: 'atc',
  43: 'qwx',
  77: 'oxi'
}

varza wszystko, co może być zmienne. Nazwy, które mogą mylić osoby czytające kod, nawet jeśli są stałe lokalnie i nie są odpowiednie let(tj. Nie są wypełnione w prostej deklaracji bezpośredniej), ubiegają się o deklarację za pomocą var. Na przykład:

var output = '\n'
lines.forEach(line => {
  output += '  '
  output += line.trim()
  output += '\n'
})
output += '\n---'

for (let parent in parents) {
  var definitions = {}
  definitions.name = getName(parent)
  definitions.config = {}
  definitions.parent = parent
}

Dalsze komentarze i możliwe przyszłe aktualizacje tutaj .

JavaScript jest trochę wyjątkowy, ponieważ zmienne mogą być funkcjami i takimi, ale weź pod uwagę C #, Java lub inny podobny język w stylu C:

const public void DoSomething()

Jest constto dziwne, a to dlatego, że deklaracje metod w tych językach nie mogą się zmienić, gdy zostaną one skompilowane w coś innego, to jest to, co robią, bez względu na wszystko (ignorując niektóre okropne hacki, które mogą istnieć).

Dlaczego JavaScript powinien być inny? Więc nie jest skompilowany, ale to nie znaczy, że powinniśmy porzucić bezpieczeństwo, które kompilatory mogą zapewnić. Użycie constsłowa kluczowego zapewnia nam większe bezpieczeństwo, co z pewnością doprowadzi do bardziej niezawodnych aplikacji.