Pourquoi le récent changement de suppression / omission des points-virgules de Javascript?
Il semble être à la mode récemment d'omettre les points-virgules de Javascript. Il y avait un article de blog il y a quelques années soulignant qu'en Javascript, les points-virgules sont facultatifs et l'essentiel de l'article semblait être que vous ne devriez pas vous embêter avec eux car ils sont inutiles. La publication, largement citée, ne donne aucune raison impérieuse de ne pas les utiliser, mais le fait de les laisser de côté a peu d'effets secondaires.
Même GitHub a sauté sur le mouvement sans point-virgule, nécessitant leur omission dans tout code développé en interne, et un commit récent au projet zepto.js par son mainteneur a supprimé tous les points-virgules de la base de code. Ses principales justifications étaient:
- c'est une question de préférence pour son équipe;
- moins de frappe
Y a-t-il d'autres bonnes raisons de les laisser de côté?
Franchement, je ne vois aucune raison de les omettre, et certainement aucune raison de revenir sur le code pour les effacer. Cela va également à l'encontre de ( années de ) pratique recommandée , pour laquelle je n'achète pas vraiment l'argument "culte du fret". Alors, pourquoi toute la haine virgule récente? Y a-t-il une pénurie imminente? Ou est-ce juste la dernière mode Javascript?
Je suppose que ma raison est la plus obscure: je programme dans trop de langues différentes en même temps (Java, Javascript, PHP) - qui nécessitent ';' donc plutôt que de former mes doigts et mes yeux que le ';' n'est pas nécessaire pour javascript, j'ajoute toujours le ';'
L'autre raison est la documentation: en ajoutant le ';' Je m'indique explicitement où j'attends la fin de la déclaration. Là encore, j'utilise aussi {} tout le temps.
L'argument du nombre d'octets que je trouve irritant et inutile:
1) pour les bibliothèques communes comme jquery: utilisez le google CDN et la bibliothèque sera probablement déjà dans le cache du navigateur
2) versionnez vos propres bibliothèques et définissez-les pour qu'elles soient mises en cache pour toujours.
3) gzip et minimisez si vraiment, vraiment nécessaire.
Mais vraiment combien de sites ont comme plus gros goulot d'étranglement de vitesse la vitesse de téléchargement de leur javascript? Si vous travaillez pour un site parmi les 100 meilleurs comme Twitter, Google, Yahoo, etc. peut-être. Le reste d'entre nous devrait juste s'inquiéter de la qualité du code et non des guerres religieuses point-virgule.
Il facilite le chaînage des méthodes et rend les différences de nettoyage plus propres
Alors disons que je jQuerying et j'ai
$('some fancy selector')
.addClass()
.attr();
Si je veux ajouter des choses et garder ma différence de validation basée sur les lignes petite, je dois l'ajouter au-dessus de attr. C'est donc une pensée plus longue que simplement "ajouter à la fin". Et qui veut penser? =)
$('some fancy selector')
.addClass()
// new method calls must go here
.attr();
Mais, quand je laisse tomber les points-virgules, je peux simplement ajouter et l'appeler un jour
$('some fancy selector')
.addClass()
.attr()
+ .animate()
+ .click()
De plus, si je décide de supprimer la dernière méthode, je n'ai pas à réaffecter le point-virgule et à polluer à nouveau mon commit.
$('some fancy selector')
.addClass()
.attr()
.animate()
- .click()
Vers l'uggo
$('some fancy selector')
.addClass()
.attr()
+ .animate();
- .animate()
- .click();
les points-virgules en JavaScript sont facultatifs
Ma raison personnelle de ne pas utiliser de points-virgules est le trouble obsessionnel-compulsif.
Lorsque j'utilise des points-virgules, j'oublie 2% d'entre eux et je dois constamment les vérifier/les rajouter.
Lorsque je n'utilise pas de points-virgules, je n'en mets jamais accidentellement, donc je n'ai jamais à les vérifier/supprimer.
Il n'y a pas de surcharge d'informations, seulement une mauvaise conception.
- Edward Tufte
C'est un règle générale en conception graphique pour laisser de côté les éléments inutiles et les ornements pour réduire le bruit.
Moins d'éléments visuels à l'écran signifie moins de travail pour notre cerveau pour analyser les informations utiles réelles.
let foo = 1
vs.
let /* variable */ foo = 1; // EOL
Un exemple exagéré bien sûr, mais qui illustre le principe général: des éléments visuels supplémentaires doivent être ajoutés si et seulement s'ils servent un objectif. Alors, les points-virgules servent-ils un but?
Les raisons historiques d'utiliser des points-virgules en JavaScript étaient les suivantes:
- Maintenir la similitude avec C/Java
- Évitez les problèmes de compatibilité avec les navigateurs et les outils mal écrits
- Aider les humains et les machines à détecter les erreurs de code
- L'insertion automatique de points-virgules comporte pénalité de performance
Les problèmes de compatibilité sont à peu près un non-problème aujourd'hui. Les linters modernes peuvent détecter toute erreur de code tout aussi bien sans point-virgule. La similitude avec C/Java/PHP peut toujours être prise en compte (voir réponse acceptée par Pat), mais ce n'est pas parce que d'autres langages contiennent des éléments de syntaxe superflus que nous devons les conserver en JavaScript, d'autant plus que beaucoup d'autres langues (Coffeescript, Python, Ruby, Scala, Lua) n'en ont pas besoin.
J'ai fait un test rapide pour voir s'il y avait une pénalité de performance en V8. C'est Io.js qui analyse un fichier JavaScript de 41 Mo (Lodash répété 100 fois) avec des points-virgules, puis avec des points-virgules supprimés:
$ time node lodashx100.js
node lodashx100.js 2.34s user 1.30s system 99% cpu 3.664 total
$ time node lodashx100s.js
node lodashx100s.js 2.34s user 1.15s system 99% cpu 3.521 total
Tout le monde doit décider de son propre style de codage préféré pour ses projets, mais je ne vois plus aucun avantage tangible à utiliser des points-virgules, donc pour réduire le bruit visuel, je me suis arrêté.
J'ai récemment écrit un analyseur/analyseur pour JavaScript, où j'ai dû implémenter minutieusement ASI, et j'ai également ma copie de Crockford JavaScript: The Good Parts sur ma bibliothèque, qui préconise toujours en utilisant des points-virgules. L'intention était bonne, mais cela n'aide pas toujours dans la pratique.
De toute évidence, les personnes qui écrivent des frameworks comme jQuery, zepto, etc. sont des maîtres de la syntaxe JavaScript et connaissent donc la différence entre:
return
{
status: true
};
et
return {
status: true
};
JavaScript, bien que puissant, est également un langage pour débutants et bonne chance pour l'expliquer à quelqu'un qui apprend juste ce qu'est une boucle for. Comme pour initier la plupart des gens à une nouvelle compétence, il y a des choses plus complexes que vous ne voulez pas expliquer tout de suite, alors au lieu de cela vous choisissez d'inculquer une croyance "culte du fret" à certaines choses juste pour les faire décoller. Ainsi, vous avez deux choix lorsque vous apprenez à un débutant à écrire du JavaScript:
- Dites-leur "suivez cette règle et ne demandez pas pourquoi", en leur disant de mettre un point virgule toujours à la fin de chaque ligne. Malheureusement, cela n'aide pas dans l'exemple ci-dessus, ou tout autre exemple où ASI se met en travers. Et M. ou Mme débutant programmeur est embrouillé lorsque le code ci-dessus échoue.
- Dites-leur "suivez ces deux règles et ne demandez pas pourquoi", en leur disant de ne pas se soucier des points-virgules à la fin de chaque ligne, et plutôt toujours a) Suivez
returnavec une{, et b) Lorsqu'une ligne commence par un(, ajoutez-le avec un;.
Le choix de l'option 2 est un meilleur ensemble de règles de "culte du fret" à suivre (entraînera très peu de bogues liés à ASI), et même si vous comprenez bien le sujet, vous avez moins de caractères inutiles à l'écran.
Le choix d'une convention de programmation revient en fait à choisir un sous-ensemble de la langue cible. Nous le faisons tous pour les raisons habituelles: lisibilité du code, maintenabilité, stabilité, portabilité, etc. - tout en sacrifiant potentiellement la flexibilité. Ces raisons sont de vraies raisons commerciales.
Des raisons telles que "l'enregistrement des frappes" et "les programmeurs doivent apprendre les règles JavaScript" sont des raisons commerciales marginales, donc elles ont peu de poids pratique.
Dans mon cas, je devais accélérer très rapidement en JavaScript, donc tirer parti d'un sous-ensemble limité du langage était à mon avantage. J'ai donc choisi le sous-ensemble JSLint de JavaScript, activé les applications Rockstar JSLinter dans Eclipse aux paramètres les plus restrictifs que je pouvais supporter, et je n'ai pas regardé en arrière.
Je suis reconnaissant de pouvoir éviter les détails de la différence entre "==" et "===", ou les détails de l'insertion de points-virgules, car j'ai déjà une liste de tâches très élevée et ces détails ne le seront pas aider à faire ces travaux une seconde plus tôt.
Bien sûr, la chose la plus importante à propos d'une convention est la cohérence, et la considérer comme un sous-ensemble linguistique contribue à renforcer cet impératif. Et même si cela peut ne pas aider à répondre à la question du PO, je pense que cela pourrait aider à sa formulation pratique.
Une question assez ancienne, mais je suis surpris que personne n'ait mentionné:
Minification: S'il vous arrive de minimiser un extrait de code JavaScript qui ne termine pas explicitement les instructions avec un caractère point-virgule, vous pourriez avoir du mal à essayer de comprendre ce qui ne va pas avec un extrait de code qui fonctionnait juste avant la minification et qui ne fonctionne plus.
Ambiguïté: Les points-virgules sont facultatifs, c'est vrai, cependant en les éliminant du code source, vous pouvez laisser certains scénarios ambigus à l'analyseur pour décider par lui-même. Si vous écrivez 100 lignes de code pour une boutique en ligne, oui, cela n'a peut-être pas d'importance, mais des tâches plus sérieuses nécessiteraient une clarté à 100%.
Il y a longtemps, j'ai lu une très belle analogie sur autre chose, mais c'est très vrai dans ce cas également: (Dans notre cas) L'élimination des points-virgules, c'est comme traverser à un feu rouge. À la fin, vous pourriez être bien ou vous pourriez être heurté par un camion.
Pourquoi ça devient plus populaire de nos jours?
Personnellement, je crois qu'avoir JavaScript s'exécute côté serveur a eu beaucoup d'effets sur la communauté JavaScript elle-même. Dans notre cas, personne ne va évidemment minimiser le JavaScript côté serveur (car le code source n'est pas censé être expédié au navigateur Web du client), donc ne pas avoir de point-virgule semble beaucoup plus sûr, ce qui est vrai; Cependant, les autres développeurs qui apprennent de ces livres, articles et vidéos rejettent malheureusement le fait que JavaScript côté serveur n'est pas exactement le même que JavaScript côté client.
Il y a de bonnes raisons de les garder.
Ils ne sont pas vraiment facultatifs, JS peut les rajouter avec une insertion automatique de point-virgule lorsqu'ils sont manquants mais ce n'est pas la même chose.
JavaScript de Douglas Crockford: The Good Parts dit à deux reprises que c'est une mauvaise idée. L'insertion automatique de points-virgules peut masquer les bogues dans votre programme et créer une ambiguïté.
JSLint n'approuve pas.
JavaScript n'a pas eu besoin de points-virgules pour terminer les instructions depuis plus d'une décennie. En effet, les caractères de nouvelle ligne sont considérés comme des terminateurs d'instructions (je pense que cela est également mentionné dans les premières spécifications ECMAScript). Cela a vraiment beaucoup de sens, d'autant plus qu'il n'y a vraiment aucune bonne raison [à ma connaissance] pour laquelle JavaScript aurait besoin d'une utilisation fréquente des points-virgules mais pas d'autres langages déclaratifs interprétés comme Ruby ou Python.
Exiger des points-virgules peut faciliter l'écriture d'un analyseur pour une langue, mais si chaque interprète prend en charge l'omission des points-virgules, alors quel est exactement le point?
Cela revient à savoir à quel point un programmeur est compétent: si vous savez que vous pouvez omettre un point-virgule, n'hésitez pas à le faire en comprenant qu'il peut y avoir ou non une conséquence. Les êtres humains sont des machines à prendre des décisions et presque toutes les décisions nécessitent un compromis ou un compromis. Le compromis de simplement jeter des points-virgules tout autour de votre code (même dans les endroits où ils ne sont pas nécessaires) est que votre code devient moins lisible (en fonction de qui vous demandez) et JSLint ne se plaindra pas (peu importe ). D'un autre côté, le compromis d'omettre les points-virgules est le fait que 90% des programmeurs JavaScript vous châtieront pour cela, mais vous finirez peut-être par profiter davantage de l'écriture de JavaScript à cause de cela.
Qu'est-ce qui vous semble le mieux? prendre des décisions éclairées ou prendre des décisions aveugles/mentalité de troupeau?
J'ai deux théories:
UNE)
La chose à propos de ce choix est qu'à l'époque, lorsque JSLint etc. était applicable, vous aviez choisi de passer beaucoup de temps à détecter des erreurs de syntaxe obscures, ou un temps raisonnable à appliquer une politique de normes sur le code.
Cependant, à mesure que nous nous rapprochons de Test unitaire - code piloté et intégration continue, le temps (et l'interaction humaine) nécessaire pour détecter une erreur de syntaxe a considérablement diminué. Les commentaires des tests indiqueront rapidement si votre code fonctionne comme prévu, bien avant qu'il ne se rapproche d'un utilisateur final, alors pourquoi perdre du temps à ajouter une verbosité facultative?
B)
Les programmeurs paresseux feront tout pour leur faciliter la vie à court terme. Moins de frappe -> moins d'effort -> plus facile. (également, ne pas avoir à point virgule évitera de forcer votre annulaire droit, évitant une certaine RSIness).
(N.B. Je ne suis pas d'accord avec l'idée d'omettre quelque chose qui désambiguïserait une déclaration).
Je ne les laisse pas de côté, mais je change les règles quand les insérer.
Les règles que la plupart des gens utilisent sont
- Avant la fin de chaque ligne
- Sauf que la ligne se termine par un
}provenant d'une instruction de fonction - Mais seulement une instruction de fonction, pas une affectation à un littéral de fonction
Ma règle est la suivante: au début de chaque ligne commençant par une accolade/support d'ouverture.
Le mien est plus simple, donc plus facile à suivre et moins sujet aux bugs. De plus, le faible nombre de points-virgules permet de trouver facilement les bogues créés en les omettant.
Un autre argument est que l'infâme return\nvalue le bogue vient de ne pas connaître ASI. Ma règle vous oblige à connaître ASI, donc les gens qui utilisent ma règle sont moins susceptibles de tomber dans le piège de ce bogue.
Nombre d'octets. Vous voyez, les personnes malveillantes essaient généralement de rentrer autant dans une seule ligne de code. Techniquement parlant, cela ne serait pas possible sans points-virgules. Je suppose qu'il s'agit davantage d'une mesure de sécurité que d'une simple exigence programmatique. D'une manière ou d'une autre, cela réduirait considérablement XSS lorsqu'il deviendrait une exigence plutôt qu'une suggestion.