Néanmoins je considère (personnellement:!-) ) qu’on a déjà assez de choses comme ça à faire attention.

Pour ce qui est des points-virgules en début de ligne, c’est encore une autre histoire ;)

J’ai lu plusieurs fois cet argument (et j’étais tout à fait convaincu) : l’insertion automatique des ; est imprévisible, car il y a trop de règles à connaître.

C’est une grosse exagération. Certaines sont déjà connues de tous : on sait qu’un retour à la ligne après un return sera interprété comme la fin de l’instruction, et l’utilisation des points-virgules explicites n’y change rien : il faut connaître cette règle. Sorti des exemples tordus, dans le monde réel il ne reste qu’une, voire deux règles à retenir (voir le premier article). Il est de toute façon intéressant de connaître le comportement du langage que l’on utilise :-)

Pour les outils, aucun des principaux outils de minification ne pose problème (voir le premier article : l’insertion des points-virgules est prise en compte par ces outils, des points virgule sont insérés). Même chose pour checker le code, j’utilise JSHint sans aucun problème avec ce type de code.

Pour l’intérêt, c’est très personnel (enfin quand on est sur son propre projet hein, pas chez les autres ;-)), et le but est surtout de démontrer que le code n’est pas « moins valide » ou « moins sûr » qu’avec des points-virgules explicites, comme on l’entend souvent.

Ceci dit, je ne suis pas totalement convaincu, mais je l’ai mis en pratique sur un projet, pour voir. Eh bien, il me semble que le code est plus lisible dans l’ensemble. Mais encore une fois, c’est un point de vue très personnel : le principal, c’est que les règles du projet soient bien définies (on a tous nos préférences pour certains détails).

Un autre jour, on parlera de placer les virgules en début de ligne ;-)

Je ne vois que deux alternatives :
– ne pas les mettre quand ils sont implicites. Conséquence: il faut connaître toutes les petites règles, notamment celles qui peuvent rendre un code non-fonctionnel.
– les mettre systématiquement.
Conséquence pour le dev: pas besoin de réfléchir, il peut se concentrer sur l’important.
Conséquence collatérale: les outils peuvent checker plus facilement le code, et le minifier.