Goto (informatique)

L’instruction goto (ou équivalent) apparaît notamment dans les langages suivants :

• Ada[3]
• Assembleur (existe mais ne s'appelle pas ainsi, par exemple JMP pour l'assembleur 8086)
• BASIC
• TI-Basic
• C
• C++
• D
• C#
• Cobol
• Common Lisp[4]
• Fortran
• Go
• Pascal
• Perl
• PHP depuis la version 5.3 (avec quelques limitations)[5]
• Ruby, depuis la version 1.9, mais seulement sous forme de plaisanterie : les instructions __goto__ et __label__ sont activées si la variable SUPPORT_JOKE est définie lors de la compilation de Ruby[6].

En Java goto est un mot réservé. Or comme l'instruction goto n'existe pas, goto devient un mot interdit et cela a pour effet, entre autres, d’empêcher l’emploi de goto comme nom de variable.

En 1966, le théorème de Böhm-Jacopini (en) a démontré que tout programme comportant des goto pouvait être transformé en programme n’utilisant que des branchements conditionnels (if, then, else) ou des boucles (while condition do instructions), éventuellement en dupliquant des portions de codes et/ou en utilisant des variables intermédiaires. Plus tard les deux auteurs ont montré que les branchements conditionnels pouvaient eux-mêmes être remplacés par des boucles.

% Début de programme
goto = -1  % pas de saut
while (goto < 0) {
  % zone sans libellé
}
if (goto == 0) {
  % Toute la partie de libellé 0
}
else if (goto == 1) {
  % Toute la partie de libellé 1
}
% ...
else if (goto == n) {
  % Toute la partie de libellé n
}

try :
    for i in range(10) :
        for j in range(10) :
            if TABLE[i][j] == 1:
                raise StopIteration
except StopIteration :
    pass

Bien que lors du meeting pré-ALGOL tenue en 1959, Heinz Zemanek ait explicitement exprimé des doutes sur la nécessité du GOTO, à l'époque, personne n'y prête attention, y compris Edsger Dijkstra, qui deviendra plus tard un opposant emblématique de l'instruction GOTO[8]. Les années 1970 et 1980 ont connu une baisse de l'utilisation des GOTO en faveur de la « programmation structurée », en effet, l'instruction GOTO amenait à un « code spaghetti inmaintenable ». Certaines normes de style de programmation déconseillent l'utilisation des instructions GOTO[9]. Il a, cependant, suscité un débat important parmi les informaticiens, éducateurs, concepteurs de langage et les programmeurs d'applications qui ont vu un changement lent, mais régulier, de l'usage autrefois omniprésent du GOTO. La critique probablement la plus célèbre de l'instruction GOTO est une lettre à l'éditeur des Comm. of the ACM de 1968 dû à Edsger Dijkstra intitulée Go To Statement Considered Harmful[8] - [10]. Dans cette lettre à l'éditeur, Dijkstra a fait valoir que les instructions GOTO devraient être supprimés dans les langages de niveau supérieur car ils compliquent la compréhension, la maîtrise, l'analyse, la vérification et la maintenance des programmes, tout en y introduisant des erreurs difficiles à diagnostiquer. Cette diatribe a initié un débat, notamment 19 ans après à une époque où les langages déclaratifs ont déjà pris de l'ampleur, une lettre GOTO Considered Harmful[11]. Un autre point de vue plus synchronique est présenté par Donald Knuth dans Structured Programming with go to Statements, où il analyse de nombreuses tâches de programmation, dans lesquelles il constate que, dans certaines d'entre elles, le GOTO est la construction de la langue la plus optimale à utiliser[12]. Des codeurs du noyau Linux comme Linus Torvalds ou Steve McConnell, se démarquent du point de vue de Dijkstra, indiquant que le GOTO peut amener à une l'amélioration de la performance du programme, de la taille et de la clarté du code, mais seulement lorsqu'il est utilisé de manière raisonnable[13] - [14]. Selon John Regehr, en 2013, il y avait environ 100 000 instructions GOTO dans le code du noyau Linux[15]. En effet, le GOTO est souvent le résultat de code C produit automatiquement, par exemple dans la traduction d'un automate. En 2016, il est inexistant dans les langages de haut niveau. Le langage C est devenu plutôt un langage dans lequel d'autre logiciels produisent du code (voir l'article langage dédié).

• Les labels doivent être explicites.
• Le nombre des labels et des renvois doit être faible.
• Il faut envisager autre chose et faire autre chose si c'est plus simple : break, continue, fonctions...

• (en) Edsger W. Dijkstra, « Letters to the editor: Go to statement considered harmful », Communications of the ACM, vol. 11, n^o 3,‎ mars 1968, p. 147–148 (DOI 10.1145/362929.362947, lire en ligne)
• (en) L. Ramshaw, « Eliminating go to's while preserving program structure », Journal of the ACM, vol. 35, n^o 4,‎ 1988, p. 893 (DOI 10.1145/48014.48021)