Mode strict JavaScript : à quoi sert 'use strict' ?

Le mode strict, une variante plus rigoureuse de JavaScript

JavaScript traîne une longue histoire, et avec elle son lot de décisions discutables : des affectations qui créent silencieusement des variables globales, un this dont le sens change selon la façon dont on appelle une fonction, des noms de paramètres dupliqués qui passaient... sans broncher. Casser tout ça briserait le Web, alors le TC39 (le comité qui maintient le langage) a choisi une autre voie : un mode optionnel qui lime les aspérités.

Ce mode optionnel, c'est le mode strict. Pour l'activer, il suffit d'une seule ligne en haut d'un fichier ou d'une fonction :

Si tu exécutes ce code, tu vas tomber sur une erreur ReferenceError: x is not defined. Sans la directive, le même code crée tranquillement une variable globale x et affiche 10. Même langage, mais deux jeux de règles bien différents.

La directive 'use strict'

La directive, c'est tout bêtement une chaîne de caractères : 'use strict'; ou "use strict";. Elle doit impérativement apparaître en tout premier, que ce soit au début du script ou d'une fonction. S'il y a quoi que ce soit avant — ne serait-ce qu'une expression perdue — le moteur la considère comme une simple chaîne et l'ignore purement et simplement.

Vous pouvez limiter le mode strict à une seule fonction en plaçant la directive à l'intérieur de celle-ci. En pratique, plus personne ne fait ça : soit vous écrivez des modules (stricts par défaut), soit vous basculez le fichier entier.

Ce que le mode strict change vraiment

Le mode strict, ce n'est pas une règle unique, c'est tout un lot. Les points marquants :

• Affecter une valeur à une variable non déclarée déclenche une erreur au lieu de créer une globale.
• this, dans un appel de fonction classique, vaut undefined et non l'objet global.
• Les noms de paramètres en double (function f(a, a) {}) deviennent une erreur de syntaxe.
• Affecter une valeur à une propriété en lecture seule lève une erreur au lieu d'échouer silencieusement.
• Supprimer une variable ou une fonction simple provoque une erreur.
• Quelques mots réservés pour l'avenir (implements, interface, package, private, protected, public, static, yield) ne peuvent plus servir de noms de variables.

Un petit tour d'horizon :

Dans chaque cas, le moteur a repéré une probable erreur plus tôt. C'est toute la valeur du mode strict, résumée en une phrase.

Le bug silencieux de la variable globale

C'est la raison numéro un d'activer le mode strict en JavaScript. Sans lui, une simple faute de frappe se transforme en variable globale :

// Mode non-strict (à ne pas faire)
function setup() {
    usernmae = 'Ada';   // faute de frappe — crée window.usernmae
}

setup();
console.log(username);  // undefined — la vraie variable n'a jamais été définie

Le programme tourne. Aucune erreur. Le bug n'apparaît que plus tard, quand quelque chose qui aurait dû lire username tombe sur undefined. En mode strict, cette même faute de frappe déclenche une erreur dès l'exécution, et tu corriges le problème en quelques secondes au lieu de plusieurs heures.

Le JavaScript moderne est strict par défaut

Voilà ce qui surprend pas mal de monde : la plupart du code JavaScript que tu écris aujourd'hui est déjà en mode strict, sans que tu aies tapé 'use strict' où que ce soit.

Deux grandes sources de mode strict automatique :

• Les modules ES. Tout fichier .mjs, toute balise <script type="module"> et tout ce qui est chargé via import/export s'exécute en mode strict. Pas besoin de directive.
• Le corps des classes. Toutes les instructions à l'intérieur d'un class { ... } sont strictes, même si le fichier qui les entoure ne l'est pas.

Alors, quand faut-il vraiment écrire 'use strict'; soi-même ? Uniquement dans les scripts classiques — c'est-à-dire du JS à l'ancienne chargé avec une balise <script> toute simple, ou de vieux fichiers Node.js qui utilisent require sans bundler de modules. Pour tout ce qui est récent, les modules s'en chargent à votre place.

Le mode strict change le this dans les fonctions classiques

Il y a un comportement qui mérite qu'on s'y attarde, parce qu'il piège souvent les débutants. En mode non strict, si vous appelez une fonction classique sans objet devant, this pointe vers l'objet global (window dans le navigateur, global sous Node). En mode strict, this vaut undefined :

C'est en général exactement ce qu'on veut. Quand this vaut undefined, un bug où on a oublié de lier une méthode saute aux yeux tout de suite. S'il pointait silencieusement vers l'objet global, le bug resterait caché jusqu'à ce que quelque chose casse bien plus loin.

Ce que le mode strict ne fait pas

Le mode strict, c'est un resserrement au moment de la compilation et à l'exécution — il ne t'apporte pas de typage, il ne détecte pas les déréférencements de null, et il ne te prévient pas des variables inutilisées. Ça, c'est le boulot de TypeScript, ESLint et ton éditeur. Vois plutôt le mode strict comme un correctif pour une poignée de pièges au niveau du langage, pas comme un filet de sécurité complet.

Et attention, ce n'est pas synonyme de « JavaScript moderne ». On peut écrire du code catastrophique en mode strict, et du code impeccable sans la directive. Le mode strict rend simplement plus difficiles certaines erreurs bien précises.

À retenir

• 'use strict'; en tête d'un fichier ou d'une fonction active une variante plus stricte de JavaScript.
• Les fautes de frappe ne créent plus de variables globales, this ne bascule plus silencieusement sur l'objet global, et une poignée d'autres pièges deviennent des erreurs.
• Les modules ES et les corps de class sont en mode strict automatiquement — tu n'as quasiment jamais besoin d'écrire la directive toi-même.
• L'objectif, c'est d'attraper les bugs plus tôt, pas d'activer de nouvelles fonctionnalités.

La suite : les commentaires

Tu as vu les directives, les points-virgules, et les règles qui comptent pour le moteur. Place maintenant aux notes que toi tu laisses pour les futurs lecteurs : comment fonctionnent les commentaires en JavaScript, et quand ça vaut vraiment le coup d'en écrire.