Le code JavaScript : une suite d'instructions
Un programme JavaScript, c'est avant tout une liste d'instructions — des ordres que le moteur exécute de haut en bas. Déclarer une variable est une instruction. Appeler une fonction aussi. Un bloc if ou une boucle for, pareil. Ces instructions sont séparées les unes des autres par des points-virgules.
Trois instructions, trois points-virgules. Le moteur exécute la première, puis la deuxième, puis la troisième. Rien de sorcier.
Les espaces et l'indentation ne veulent rien dire pour le parseur. Tu pourrais très bien coller les trois instructions sur une seule ligne, séparées par des points-virgules, et ça tournerait exactement pareil. Si on indente, c'est pour nous, les humains, pas pour le moteur.
Les blocs regroupent plusieurs instructions
Les accolades { } délimitent un bloc : un ensemble d'instructions que le moteur traite comme un tout. Tu en croiseras partout : corps de fonctions, branches d'un if, corps de boucles.
Les deux appels à console.log entre accolades forment le corps du if. Remarque qu'il n'y a pas de point-virgule après l'accolade fermante } — un bloc n'est pas une instruction qu'il faut terminer. L'instruction if dans son ensemble se termine avec la fin du bloc.
C'est un piège classique pour ceux qui viennent de langages où chaque } réclame un ; derrière. En JavaScript, un bloc isolé ou un bloc de contrôle de flux, non.
Expressions et instructions : quelle différence ?
Une distinction à bien avoir en tête dès le départ : une expression produit une valeur, une instruction effectue une action.
2 + 3est une expression. Elle s'évalue à5.let x = 2 + 3;est une instruction. Elle déclare une variable et lui affecte le résultat d'une expression.console.log("hi")est une expression (un appel de fonction renvoieundefined), mais écrit seul sur sa ligne avec un point-virgule, il devient une instruction d'expression.
La plupart du temps, tu n'as même pas à y penser. Ça devient important quand tu croises des fonctions fléchées, des ternaires, ou des endroits où JavaScript attend une expression mais que tu lui refiles une instruction (ou l'inverse).
Faut-il mettre des points-virgules en JavaScript ?
Soyons honnêtes : JavaScript embarque un mécanisme appelé Automatic Semicolon Insertion (ASI), qui ajoute pour toi les points-virgules manquants à la plupart des sauts de ligne. Résultat, un code comme celui-ci tourne sans souci :
Sans point-virgule, pas d'erreur. L'ASI regarde chaque saut de ligne et se demande : « le prochain token peut-il prolonger l'instruction en cours ? » Si non, il insère un point-virgule.
À cause de l'ASI, deux styles coexistent dans la nature :
- Toujours des points-virgules. La majorité des codebases, des tutoriels et des guides de style.
- Jamais de points-virgules. Adopté par certains projets modernes (le style Standard, quelques codebases React). Ça s'appuie sur l'ASI plus deux-trois astuces défensives.
Les deux fonctionnent. Aucun n'est « faux ». Ce qui l'est, en revanche, c'est l'incohérence — mélanger les deux styles dans un même fichier rend les bugs beaucoup plus difficiles à repérer.
Les pièges de l'ASI en JavaScript
L'ASI fait ce qu'il faut dans environ 99 % des cas. Le 1 % restant, ce sont les lignes qui commencent par un token capable de prolonger la ligne précédente. Les coupables : [, (, `, +, - et /.
Regarde ça :
On pourrait s'attendre à ce que x et y soient échangés. Mais non : l'ASI n'insère pas de point-virgule avant [x, y], parce que 10[x, y] est syntaxiquement valide (ça ressemble à un accès par index sur le nombre 10). Le parseur colle donc la ligne 2 et la ligne 3 en une seule grosse expression, et tu te retrouves avec une erreur à l'exécution ou un résultat aberrant.
La solution, c'est soit d'ajouter un point-virgule à la fin de la ligne 2 :
Ou alors, si tu adoptes le style sans point-virgule, tu peux mettre un point-virgule en début de la ligne à risque :
Ce ; en début de ligne, c'est la parade défensive des bases de code qui n'utilisent pas de points-virgules. Ça paraît bizarre au premier coup d'œil, jusqu'à ce qu'on comprenne à quoi ça sert.
Le piège du return
Il y a un cas d'ASI qui mérite vraiment d'être retenu, parce qu'il provoque des bugs silencieux. Si tu mets un retour à la ligne juste après return, l'ASI insère un point-virgule à cet endroit, et la fonction renvoie undefined :
L'auteur voulait renvoyer un objet. Sauf que l'ASI a vu return en fin de ligne et a immédiatement terminé l'instruction. Résultat : le littéral objet devient du code mort, inaccessible.
La solution, c'est de placer la valeur sur la même ligne que return :
La même règle s'applique à throw, break, continue et yield : ne mettez jamais de saut de ligne entre le mot-clé et sa valeur.
Une règle simple qui marche à tous les coups
Si vous débutez, le plus sûr est de suivre ces quelques principes :
- Mettez explicitement un point-virgule à la fin de chaque instruction.
- N'en mettez pas après une
}qui ferme un bloc deif,for,while, une déclaration de fonction ou le corps d'une classe. - Mettez-en après une
}quand il s'agit d'un objet littéral ou d'une fonction expression affectée à une variable :const f = function() {};. - Utilisez un formateur (Prettier, ou ESLint avec une règle de style) et n'y pensez plus. C'est lui qui applique les conventions choisies par votre équipe.
Cette règle n'est pas une loi universelle — c'est simplement la convention que tu retrouveras dans la majorité du code JavaScript que tu liras. Tiens-t'en à ça tant que tu n'as pas de bonne raison de faire autrement.
Sensibilité à la casse et identifiants
Deux petites règles qui ont leur place ici aussi :
- JavaScript est sensible à la casse.
userName,usernameetUserNamesont trois identifiants distincts. - Un identifiant peut contenir des lettres, des chiffres,
_et$, mais ne peut pas commencer par un chiffre. Il ne peut pas non plus correspondre à un mot réservé commeclass,returnoufunction.
Le $ est légal, mais par convention on le réserve plutôt à des usages liés à certaines bibliothèques (jQuery l'a beaucoup utilisé à l'époque, et quelques moteurs de templates s'en servent encore). Dans ton propre code, tu ne l'utiliseras quasiment jamais.
La suite : le mode strict
Le JavaScript moderne tourne discrètement dans une variante plus stricte du langage, appelée strict mode, qui transforme certains comportements laxistes en véritables erreurs. Les modules ES et le corps des classes sont en mode strict par défaut, mais ça vaut le coup de savoir ce que ça change concrètement — on en parle dans la page suivante.
Questions fréquentes
Faut-il mettre des points-virgules en JavaScript ?
Techniquement non : JavaScript dispose de l'insertion automatique de points-virgules (ASI), qui les ajoute pour vous à la plupart des sauts de ligne. En pratique, la majorité des équipes continue de les écrire explicitement, parce que l'ASI a quelques cas piégeux — notamment les lignes qui commencent par [, (, `, +, - ou / — où elle se trompe. Choisissez un style et laissez un formateur comme Prettier s'en occuper.
Qu'est-ce que l'insertion automatique de points-virgules (ASI) en JavaScript ?
L'ASI, c'est la règle qui permet à JavaScript d'ajouter tout seul les points-virgules manquants en fin de ligne, dès que le token suivant ne peut pas prolonger l'instruction en cours. C'est pour ça que let x = 1 fonctionne sans point-virgule. Ça coince quand une ligne commence par un caractère qui peut prolonger la précédente — comme [ ou ( — et là, JavaScript colle silencieusement les deux lignes ensemble.
À quoi ressemble une instruction JavaScript ?
Une instruction, c'est une action : une déclaration de variable, un appel de fonction, un if, une boucle. Les instructions sont séparées par des points-virgules (explicites ou insérés par l'ASI). Les blocs d'instructions se mettent entre { }. Les espaces et l'indentation sont ignorés par le parseur — la mise en forme, c'est pour les humains, pas pour le moteur.
