Combien devrais-je utiliser 'let' vs 'const' dans ES6?

J'ai écrit beaucoup de code ES6 pour io.js récemment. Il n’ya pas beaucoup de code dans la nature à apprendre, alors j’ai l’impression de définir mes propres conventions au fur et à mesure.

Ma question est quand utiliser constvs let.

J'ai appliqué cette règle: si possible, utilisez const. Utilisez uniquement letsi vous savez que sa valeur doit changer. (Vous pouvez toujours revenir en arrière et changer un consten un lets'il s'avère que vous devez changer sa valeur plus tard.)

La principale raison de cette règle est qu'il est facile à appliquer de manière cohérente. Il n'y a pas de zones grises.

En réalité, lorsque j’applique cette règle, en pratique, 95% de mes déclarations le sont const. Et cela me semble bizarre. Je n'utilise que letpour des choses comme idans une forboucle, ou occasionnellement pour des choses comme les totaux accumulés de Fibonacci (qui ne sont pas très fréquents dans la vie réelle). Cela m'a surpris - il s'avère que 95% des «variables» dans mon code ES5 à ce jour étaient pour des valeurs qui ne varient pas. Mais voir constpartout dans mon code me semble mal.

Ma question est donc la suivante: est-il acceptable d’utiliser constautant? Devrais-je vraiment faire des choses comme const foo = function () {...};?

Ou devrais-je réserver constpour ce genre de situations où vous codez en dur un littéral en haut d'un module - le genre que vous faites en majuscules, comme const MARGIN_WIDTH = 410;?

Ma réponse ici n'est pas spécifique à javascript.

En règle générale, dans toute langue qui me permet de le faire de manière semi-facile, je dirais que vous devez toujours utiliser const / final / readonly / quel que soit le nom utilisé dans votre langue, lorsque cela est possible. La raison est simple, il est beaucoup plus facile de raisonner sur le code lorsqu'il est évident de savoir ce qui peut changer et ce qui ne peut pas changer. Et en plus de cela, dans de nombreuses langues, vous pouvez obtenir un support d’outil vous indiquant que vous faites quelque chose de mal lorsque vous affectez accidentellement une variable que vous avez déclarée comme const.

Revenir en arrière et changer un const en un let est extrêmement simple. Et aller par défaut vous fait réfléchir à deux fois avant de le faire. Et c'est dans de nombreux cas une bonne chose.

Combien de bugs avez-vous vu impliquant des variables changeant de manière inattendue? J'imagine beaucoup. Je sais que la majorité des bogues que je vois impliquent des changements d'état inattendus. Vous ne vous débarrasserez pas de tous ces bugs en utilisant généreusement const, mais vous vous débarrasserez de beaucoup d'entre eux!

En outre, de nombreux langages fonctionnels ont des variables immuables où toutes les variables sont constantes par défaut. Regardez Erlang par exemple ou F #. Le codage sans affectation fonctionne parfaitement dans ces langues et est l’une des nombreuses raisons pour lesquelles les gens aiment la programmation fonctionnelle. Il y a beaucoup à apprendre de ces langages sur la gestion d'état afin de devenir un meilleur programmeur.

Et tout commence par être extrêmement libéral avec const! ;) Il ne reste plus que deux personnages à écrire, alors allez-y et consttout le reste!

Soyez prudent, car les constclés d'objet sont mutables.

De là: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const

les clés d'objet ne sont pas protégées

Considérons cet exemple:

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

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

Même chose pour les tableaux:

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

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

Je n'ai pas encore décidé moi-même, mais j'envisage d'utiliser constpour tous les non-tableaux / non-objets et letpour les objets / les tableaux.

Ne t'inquiète pas pour ça. constest un ajout étonnant à JavaScript, et je vous recommanderais de l’utiliser dans tous les endroits où cela fait sens. Cela rend le code plus robuste.

En ce qui concerne les objets, constprotégera votre variable contre la réaffectation, mais si vous avez besoin d’objets immuables, vous aurez besoin de la Object.freezeméthode, voir ci-dessous.

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

constprotégera uniquement contre la réaffectation, et la freezeméthode protégera toutes les propriétés immédiates. Si vous souhaitez que toutes les propriétés imbriquées soient également immuables, vous devez les récursivement freeze.

Dans mon ES6 constn’est pas une question d’immutabilité , j’explique ce que constsignifie exactement selon les spécifications.

Sur la base de ces faits objectifs, voici ma préférence personnelle:

[…] Il est logique d'utiliser letet constcomme suit dans votre code ES6:

• utiliser constpar défaut
• à utiliser uniquement letsi une nouvelle liaison (c'est-à-dire toute forme de réaffectation) est nécessaire
• ( varne devrait pas être utilisé dans ES6)

Aussi subjectif que cela puisse être, c'est un fait que cela correspond le mieux à l'intention de la spécification.

Les personnes qui utilisent letpar défaut traitent généralement les constvariables comme des constantes (ce qu'elles ne sont pas nécessairement, à dessein!). À chacun son goût, mais je préfère utiliser les choses pour les buts pour lesquels elles ont été conçues, et non pour des raisons inventées que les gens attribuent en se basant sur un malentendu.

Utiliser constuniquement pour les constantes revient à utiliser l' <aside>élément HTML uniquement pour le contenu de la barre latérale.

Mon approche personnelle, pensée pour aider à la lisibilité et à la compréhension du code:

letne concerne que les variables à vie courte, définies sur une seule ligne et non modifiées après. Généralement, les variables qui ne sont là que pour diminuer le nombre de saisies. Par exemple:

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]
  ...
}

constpour tous les noms connus pour être constants sur tout le module. Non compris les valeurs constantes localement. Dans valuel'exemple ci-dessus, par exemple, la portée est constante et elle peut être déclarée avec const, mais comme il existe de nombreuses itérations et que, pour chacune d'entre elles, il existe une valeur du même nom , "valeur", qui pourrait amener le lecteur à penser qu'il valueest toujours le même. Les modules et les fonctions sont le meilleur exemple de constvariables:

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

varpour tout ce qui peut ou non être variable. Les noms qui peuvent confondre les lecteurs du code, même s’ils sont constants localement et qu’ils ne conviennent pas let(c’est-à-dire qu’ils ne sont pas complétés dans une simple déclaration directe), demandent à être déclarés avec var. Par exemple:

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
}

Autres commentaires et futures mises à jour possibles ici .

JavaScript est un peu spécial en ce que les variables peuvent être des fonctions et autres, mais considérons en C #, Java ou un autre langage de style C similaire:

const public void DoSomething()

C'est constétrange, et c'est parce que les déclarations de méthode dans ces langages ne peuvent pas changer, une fois qu'elles sont compilées dans quelque chose d'autre, c'est ce qu'elles font, peu importe ce qui se passe (en ignorant quelques horribles piratages pouvant exister).

Pourquoi JavaScript devrait-il être différent? Donc, ce n'est pas compilé, mais cela ne signifie pas que nous devrions jeter la sécurité que les compilateurs peuvent fournir. L'utilisation du constmot clé nous donne plus de sécurité, ce qui conduira sûrement à des applications plus robustes.