08.10.2026 · Signal Titans Editorial

Dijkstra n’a jamais intitulé son texte « Go To Statement Considered Harmful ». C’est son éditeur qui l’a fait.

Edsger W. Dijkstra montrant des formules au tableau, dans une composition éditoriale sombre avec des flèches de saut courbes entre des lignes de code.

En 1968, un informaticien néerlandais envoie par la poste un court article aux Communications of the ACM. Il l’intitule « A Case against the GO TO Statement » (en substance : plaidoyer contre l’instruction GO TO).

Personne ne se souvient de ce titre.

Le rédacteur en chef, Niklaus Wirth, veut le publier vite. Le moyen le plus rapide est de le faire paraître sous forme de lettre à la rédaction, et au passage, le titre change. Le texte paraît dans le numéro de mars 1968, aux pages 147 et 148, sous le titre « Go To Statement Considered Harmful ».

L’auteur s’appelle Edsger W. Dijkstra. Plus de trente ans plus tard, il fera remarquer, pince-sans-rire, que la lettre était surtout citée par des gens qui n’en avaient lu que le titre. Ce titre est lui-même devenu un modèle. Depuis, on a accolé « X considered harmful » à presque tout en informatique.

Un texte célèbre pour la mauvaise raison

Le nouveau titre donnait à la lettre des airs d’interdiction. L’argument, lui, portait sur autre chose : la façon dont les gens pensent.

Dijkstra commençait par une observation qu’il disait défendre depuis des années : la qualité des programmeurs est « une fonction décroissante de la densité d’instructions go to dans les programmes qu’ils produisent ». Puis il tentait d’expliquer pourquoi.

Sa réponse ne tenait ni au style ni au goût. Elle tenait à l’écart entre un programme en tant que texte et un programme en tant que processus. Quand on lit du code, on voit quelque chose de statique. Quand il s’exécute, il devient une suite d’événements dans le temps. Dijkstra écrivait que « nos capacités intellectuelles sont plutôt taillées pour maîtriser des relations statiques » et que notre aptitude à nous représenter des processus qui se déroulent dans le temps est « relativement peu développée ».

Le travail du programmeur, soutenait-il, consiste donc à « réduire l’écart conceptuel entre le programme statique et le processus dynamique ». Le texte doit permettre de savoir facilement où l’on se trouve dans le programme en cours d’exécution.

Ce que le goto casse vraiment

Voici le détail concret qu’un développeur peut répéter à un collègue. Avec des séquences, des choix if/else et des boucles, on peut décrire où se trouve un programme à l’aide d’un petit jeu de coordonnées : la ligne où l’on est, la branche que l’on a prise, et le nombre de fois où chaque boucle englobante s’est exécutée. Cette description garde tout son sens quand on lit le code de haut en bas.

Un goto sans restriction détruit cela. Dès que le contrôle peut sauter n’importe où, la position dans le texte ne dit presque plus rien sur la manière dont on y est arrivé. Pour comprendre une valeur à une ligne donnée, il faut parfois rejouer tous les chemins qui ont pu y mener. Le verdict de Dijkstra était sans appel : le goto « est trop une invitation à mettre la pagaille dans son programme ».

Il voulait bel et bien le faire disparaître. La lettre conclut que l’instruction go to devrait être abolie de tous les langages de programmation de « haut niveau ». Mais sa raison tenait au raisonnement, pas aux règles.

Il n’était pas le premier, et il l’a dit

Un récit populaire fait de Dijkstra un prophète solitaire. Son propre texte, non.

Il rendait hommage à Heinz Zemanek, qui avait remis en cause le goto lors d’une réunion préparatoire à ALGOL, à Copenhague, en 1959. Il écrivait qu’il n’était « pas resté imperméable à l’influence » de Peter Landin et Christopher Strachey. Il attribuait l’instruction case à Tony Hoare et à Wirth, et mentionnait un article de 1966 de Corrado Böhm et Giuseppe Jacopini qui, selon ses mots, semblait avoir prouvé que le goto était logiquement superflu.

Puis il ajoutait un avertissement facile à manquer. Réécrire mécaniquement un organigramme embrouillé en un organigramme sans sauts, comme le permettait le résultat de Böhm–Jacopini, n’était « pas à recommander ». Supprimer le goto par la force brute pouvait laisser un code toujours impossible à suivre. Ce qui comptait, c’était une structure sur laquelle on peut raisonner, pas l’absence d’un mot-clé.

Le retour de bâton

La lettre a fait l’effet d’une bombe. Donald Knuth a écrit plus tard que Dijkstra lui avait confié avoir reçu « un torrent de lettres injurieuses ».

En décembre 1974, Knuth publie un long article au titre délibérément provocateur : « Structured Programming with go to Statements » (programmation structurée avec des instructions go to). Il trouve du mérite aux deux camps. Il montre des cas, comme les sorties sur erreur et certaines boucles, où un saut discipliné peut être plus clair ou plus rapide que les alternatives, et plaide pour de meilleures constructions de langage pour les traiter. Le même article contient la phrase qui deviendra encore plus célèbre que le titre de Dijkstra : « l’optimisation prématurée est la source de tous les maux ».

La querelle ne s’est jamais complètement éteinte. En mars 1987, un lecteur nommé Frank Rubin publie « “GOTO Considered Harmful” Considered Harmful » dans la même revue, avec un petit problème de programmation qui, selon lui, se résolvait plus proprement avec un goto. Cinq réponses suivent. Dijkstra écrit une note qualifiant tout l’échange de « déception ». Il fait remarquer que l’une des versions de Rubin échouait sur une entrée vide, et résout le problème avec des boucles imbriquées.

Ce qui l’a vraiment emporté

Si vous écrivez du code aujourd’hui, vous vivez en grande partie dans le monde de Dijkstra sans vous en rendre compte. Boucles, fonctions, retours anticipés, break et continue, exceptions : ce sont toutes des formes de saut structurées et nommées. Elles vous donnent le contrôle dont vous avez besoin tout en gardant le texte comme une carte fiable du processus en cours d’exécution.

Le goto lui-même n’a pas disparu. Le document sur le style de code du noyau Linux le recommande dans un cas précis : « lorsqu’une fonction sort à plusieurs endroits et qu’un travail commun, comme le nettoyage, doit être effectué ». C’est exactement le type d’usage discipliné et lisible que Knuth défendait en 1974. C’est aussi cohérent avec la vraie préoccupation de Dijkstra, car un seul saut clairement nommé vers un bloc de nettoyage ne cache pas par où le programme est passé.

La leçon derrière le titre

Trois choses méritent d’être retenues de cette histoire.

La version célèbre n’est pas toujours celle de l’auteur. C’est le titre d’un rédacteur en chef, et non celui de Dijkstra, qui a fixé la façon dont des millions de programmeurs se souviennent de l’argument.
Les débats sur la syntaxe sont souvent des débats sur le raisonnement. Ce qui importait à Dijkstra, c’était de savoir si un lecteur pouvait prédire l’état d’un programme à partir de son texte.
Les règles survivent à leurs raisons. « N’utilisez jamais goto » est devenu un slogan. « Rendez le flot de contrôle facile à suivre » est le principe dont il est issu.

Ce combat n’a jamais vraiment consisté à imposer une règle. Il s’agissait de garder le code compréhensible pour ceux qui doivent le lire.

Alors la prochaine fois que vous ajoutez un flag, un callback ou un événement qui fait sauter le contrôle à un endroit inattendu, posez la question de Dijkstra : quelqu’un qui lit cette ligne peut-il encore savoir comment le programme est arrivé ici ?