Pourquoi le récent passage à la suppression / suppression des points-virgules de Javascript?

Il semble être à la mode récemment de supprimer les points-virgules de Javascript. Il y a quelques années, un article sur un blog soulignait qu'en Javascript, les points-virgules sont facultatifs et que l'essentiel de l'article semblait indiquer que vous ne devriez pas vous en soucier, car ils sont inutiles. Le message, largement cité, ne donne aucune raison impérieuse de ne pas les utiliser, mais le fait de les ignorer a peu d’effets secondaires.

Même GitHub a suivi le mouvement sans semi-virgule, exigeant leur omission dans tout code développé en interne, et un commit récent du projet zepto.js par son responsable 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 au code pour les effacer. Cela va également à l’encontre de la pratique recommandée (des années ) , pour laquelle je n’achète pas vraiment l’argument du "culte du fret". Alors, pourquoi tous les récents points-virgules détestés? Y a-t-il une pénurie imminente? Ou est-ce juste la dernière lubie Javascript?

Je suppose que ma raison est la plus légère: je programme simultanément dans trop de langages différents (Java, Javascript, PHP), ce qui nécessite ';' alors plutôt que d'entraîner mes doigts et les yeux que le ';' n’est pas nécessaire pour javascript, j’ajoute toujours le ';'

L'autre raison est la documentation: en ajoutant le ';' Je me dis explicitement où je m'attends à ce que la déclaration se termine. Ensuite, j'utilise {} tout le temps aussi.

L’argument du nombre entier d’octets me semble irritant et inutile:

1) pour les bibliothèques communes comme jquery: utilisez le CDN google et la bibliothèque sera probablement déjà dans le cache du navigateur

2) version vos propres bibliothèques et définissez-les pour être mis en cache pour toujours.

3) gzip et minimiser si vraiment, vraiment nécessaire.

Mais vraiment, combien de sites ont pour goulet d’étranglement la vitesse de téléchargement de leur javascript? Si vous travaillez pour un des 100 meilleurs sites comme Twitter, Google, Yahoo, etc., peut-être. Le reste d'entre nous ne devrait que s'inquiéter de la qualité du code et non des guerres de religion par points-virgules.

Cela facilite l’enchaînement des méthodes et rend les diffs plus propres

Alors disons que je suis jQuerying à propos et j'ai

$('some fancy selector')
  .addClass()
  .attr();

Si je veux ajouter des éléments et garder mon diff de validation basé sur les lignes trop petit , je dois l’ajouter au-dessus de attr. Donc, c'est 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 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()

Contre l'uggo

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate();
-   .animate()
-   .click();

les points-virgules en JavaScript sont facultatifs

La raison personnelle pour laquelle je n'utilise pas de points-virgules est le TOC.

Lorsque j'utilise des points-virgules, j'en oublie 2% et je dois les vérifier / les rajouter en permanence.

Lorsque je n'utilise pas de point-virgule, je n'en mets jamais accidentellement un; je n'ai donc jamais à les vérifier / les enlever.

J'ai récemment écrit un analyseur / analyseur pour JavaScript, dans lequel je devais implémenter minutieusement ASI, et j'ai aussi mon exemplaire de JavaScript: The Good Parts de Crockford sur ma bibliothèque, qui préconise de toujours utiliser des points-virgules. L'intention était bonne, mais cela n'aide pas toujours dans la pratique.

Évidemment, les personnes qui écrivent des frameworks comme jQuery, zepto, etc. sont des maîtres de la syntaxe JavaScript et connaissent donc bien la différence entre:

return
{
    status: true
};

et

return {
    status: true
};

JavaScript, bien que puissant, est aussi un langage pour débutant et bonne chance pour l'expliquer à quelqu'un qui vient d'apprendre ce qu'est une forboucle. Comme pour initier une nouvelle compétence à la plupart des gens, il y a des choses plus complexes que vous ne voulez pas expliquer tout de suite. Vous préférez donc inculquer un «culte du fret» en certaines choses simplement pour les faire décoller. Donc, vous avez deux choix pour apprendre à un débutant à écrire du JavaScript:

1. 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 en rien l’exemple ci-dessus, ni aucun autre exemple où ASI est un obstacle. Et M. ou Mme programmeur débutant sont embarrassés lorsque le code ci-dessus échoue.
2. Dites-leur "suivez ces deux règles et ne demandez pas pourquoi", en leur disant de ne pas s'embarrasser de points-virgules à la fin de chaque ligne, et de toujours plutôt a) suivre returnavec a {, et b) quand une ligne commence par a (, précéder avec un ;.

Choisir l'option 2 est un meilleur ensemble de règles de "culte du fret" à suivre (il y aura très peu de bugs liés à ASI), et même si vous comprenez bien le sujet, vous aurez moins de caractères inutiles à l'écran.

Il n’existe pas de surcharge d’information, seulement une mauvaise conception.

- Edward Tufte

En graphisme, il est de règle générale de laisser de côté les éléments et les ornements inutiles pour réduire le bruit.

Moins d'éléments visuels à l'écran signifie moins de travail pour notre cerveau afin d'analyser les informations utiles.

let foo = 1

contre.

let /* variable */ foo = 1; // EOL

Un exemple exagéré bien sûr, mais il illustre le principe général: des éléments visuels supplémentaires doivent être ajoutés si et seulement s'ils servent à quelque chose. 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 des navigateurs et des outils mal écrits
• Aider les humains et les machines à détecter les erreurs de code
• L'insertion automatique de points-virgules entraîne une pénalité de performance

Les problèmes de compatibilité ne sont pratiquement plus un problème aujourd'hui. Les linters modernes peuvent tout aussi bien détecter les erreurs de code sans point-virgule. La similarité avec C / Java / PHP peut toujours être prise en compte (voir la 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 le conserver en JavaScript, d'autant plus que de nombreux autres langages (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 dans V8. Io.js analyse un fichier JavaScript de 41 Mo (Lodash répété 100 fois) avec des points-virgules, puis 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

Chacun doit choisir son style de codage préféré pour ses projets, mais je ne vois plus aucun avantage tangible à l’utilisation des points-virgules. C’est pourquoi, pour réduire le bruit visuel, j’ai arrêté.

Choisir une convention de programmation revient en réalité à choisir un sous-ensemble du langage cible. Nous faisons tous cela pour les raisons habituelles: lisibilité du code, maintenabilité, stabilité, portabilité, etc. - tout en sacrifiant potentiellement la flexibilité. Ces raisons sont de véritables raisons commerciales.

Des raisons telles que "sauvegarder les frappes au clavier" et "les programmeurs doivent apprendre les règles de JavaScript" sont des raisons commerciales marginales et ont donc peu de poids pratique.

Dans mon cas, j’avais besoin de maîtriser très vite le langage JavaScript. Tirer parti d’un sous-ensemble limité du langage était donc à mon avantage. J'ai donc choisi le sous-ensemble de JavaScript JSLint, 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 point-virgule, car j'ai déjà une liste de tâches d'un kilomètre et que ces détails ne seront pas aider à faire ces travaux une seconde plus tôt.

Bien entendu, l’un des aspects les plus importants d’une convention est la cohérence, et le considérer comme un sous-ensemble de langue contribue à renforcer cet impératif. Et bien que cela puisse ne pas aider à répondre à la question du PO, je pense que cela pourrait aider à l'encadrer de manière pratique.

Une question assez ancienne, mais je suis surpris que personne ne l'ait mentionné:

Minification: si vous extrayez un extrait de code JavaScript qui ne termine pas explicitement les instructions avec un point-virgule, vous aurez peut-être du mal à comprendre ce qui ne va pas avec un extrait qui fonctionnait juste avant la minification. et maintenant ne fonctionne pas.

Ambiguïté: les points-virgules sont facultatifs, bien que vrais. Toutefois, en les éliminant du code source, vous pouvez laisser certains scénarios ambigus à l’analyseur pour qu’il décide lui-même. Si vous écrivez 100 lignes de code pour une boutique en ligne, oui, peut-être que cela n'a pas d'importance, mais des tâches plus sérieuses nécessiteraient une clarté absolue.

Il y a longtemps, j'ai lu une très belle analogie sur autre chose, mais c'est également vrai dans ce cas: (Dans notre cas), éliminer les points-virgules, c'est comme si on se croisait à un feu rouge. Vous pourriez vous en tirer à la fin ou vous pourriez être renversé par un camion.

Pourquoi est-il devenu plus populaire ces jours-ci?

Personnellement, je pense que le fait d’exécuter JavaScript sur le serveur a eu de nombreux effets sur la communauté JavaScript elle-même. Dans notre cas, évidemment, personne ne minimisera le code JavaScript côté serveur (le code source n'étant pas censé être livré au navigateur Web du client), l'absence de points-virgules semble beaucoup plus sûre, ce qui est vrai; Cependant, les autres développeurs qui tirent des enseignements de ces livres, articles et vidéos, ignorent malheureusement le fait que JavaScript côté serveur n'est pas exactement identique à JavaScript côté client.

Il y a de bonnes raisons de les garder.

Ils ne sont pas vraiment optionnels, JS peut les rajouter avec une insertion de point-virgule automatique quand ils manquent, mais ce n'est pas la même chose.

Le code JavaScript de Douglas Crockford: The Good Parts indique à deux reprises que c'est une mauvaise idée. L’insertion automatique par des points-virgules peut masquer des bugs dans votre programme et créer une ambiguïté.

JSLint n'approuve pas.

JavaScript n'a pas eu besoin de points-virgules pour mettre fin aux déclarations en plus d'une décennie. En effet, les caractères de nouvelle ligne sont considérés comme des terminateurs d'instruction (je crois que cela est également mentionné dans les premières spécifications ECMAScript). Cela a beaucoup de sens, surtout qu’il n’ya aucune bonne raison [que je sache] pourquoi JavaScript nécessite l’utilisation fréquente de 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 syntaxique pour une langue, mais si chaque interprète supporte l'omission des points-virgules, alors à quoi sert-il exactement?

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, sachant qu'il peut y avoir une conséquence ou non. Les êtres humains sont des machines à prendre des décisions et presque toutes les décisions nécessitent un compromis ou un compromis. Si vous mettez juste des points-virgules tout autour de votre code (même dans les endroits où ils ne sont pas nécessaires), votre code devient moins lisible (en fonction de la personne que vous demandez) et JSLint ne se plaindra pas (qui s'en soucie). ). D'autre part, le fait d'écarter les points-virgules a pour contrepartie que 90% des programmeurs JavaScript vous châtieront, mais vous risquez de vous faire plaisir en écrivant davantage à cause de cela.

Qu'est-ce qui vous semble préférable? prendre des décisions éclairées ou prendre des décisions à l'aveugle / mentalité de groupe?

J'ai deux théories:

UNE)

Le problème avec ce choix est que, dans la journée, lorsque JSLint, etc., était applicable, vous choisissiez de passer beaucoup de temps à détecter des erreurs de syntaxe obscures ou à mettre en place une durée raisonnable pour appliquer une politique de normes en matière de code.

Cependant, au fur et à mesure que nous nous dirigeons davantage vers le code basé sur les tests unitaires et l'intégration continue, le temps (et l'interaction humaine) requis pour intercepter une erreur de syntaxe a considérablement diminué. Les résultats des tests vous indiqueront rapidement si votre code fonctionne comme prévu, bien avant qu’il n’approche un utilisateur final. Pourquoi perdre du temps à ajouter une verbosité facultative?

B)

Les programmeurs paresseux feront tout pour simplifier leur vie à court terme. Moins de frappe -> moins d'effort -> plus facile. (De plus, le fait de ne pas avoir à faire un point-virgule vous évitera de forcer l'annulaire droit, ce qui évitera des pertes de contrôle).

(NB: je ne suis pas d'accord avec l'idée d'omettre quelque chose qui désambiguise une déclaration).

Je ne les laisse pas de côté, mais je change les règles pour les insérer.

Les règles que la plupart des gens utilisent sont

• Avant chaque ligne se terminant
• Sauf que la ligne se termine par un }venant d'une instruction de fonction
• Mais seulement une instruction de fonction, pas une assignation à un littéral de fonction

Ma règle est la suivante: au début de chaque ligne en commençant par une accolade / un support d’ouverture.

Le mien est plus simple, donc plus facile à suivre et moins sujet aux insectes. De plus, le faible nombre de points-virgules facilite la recherche des bogues créés en les omettant.

Un autre argument est que le fameux return\nvaluebug provient de l'ignorance de l'ASI. Ma règle vous oblige à connaître ASI, de sorte que les personnes qui l'utilisent risquent moins de tomber dans le piège de ce bogue.

Nombre d'octets. Vous voyez, les personnes mal intentionnées essaient généralement de s’intégrer dans une seule ligne de code. Techniquement, cela ne serait pas possible sans points-virgules. Ma supposition est que c'est plus une mesure de sécurité que juste une exigence programmatique. D'une manière ou d'une autre, cela réduirait considérablement le XSS lorsqu'il deviendra une exigence plutôt qu'une suggestion.