L'utilisation de goto en vaut-elle la peine?

gotoest presque universellement découragé. Est-ce que l'utilisation de cette déclaration en vaut la peine?

Cela a été discuté plusieurs fois sur Stack Overflow, et Chris Gillum a résumé les utilisations possibles degoto :

Quitter proprement une fonction

Souvent, dans une fonction, vous pouvez allouer des ressources et devez quitter à plusieurs endroits. Les programmeurs peuvent simplifier leur code en plaçant le code de nettoyage des ressources à la fin de la fonction, tous les "points de sortie" de la fonction se trouveront sur l'étiquette de nettoyage. De cette façon, vous n'avez pas à écrire de code de nettoyage à chaque "point de sortie" de la fonction.

Quitter les boucles imbriquées

Si vous êtes dans une boucle imbriquée et devez rompre toutes les boucles, un goto peut rendre cela beaucoup plus propre et plus simple que les instructions break et les if-checks.

Améliorations des performances de bas niveau

Ceci n'est valable que dans le code critique, mais les instructions goto s'exécutent très rapidement et peuvent vous donner un coup de pouce lorsque vous vous déplacez dans une fonction. Il s'agit cependant d'une arme à double tranchant, car un compilateur ne peut généralement pas optimiser le code qui contient des gotos.

Je dirais, comme beaucoup d'autres le diraient, que dans tous ces cas, l'utilisation de gotoest utilisée comme un moyen de sortir d'un coin dans lequel on s'est codé et est généralement un symptôme de code qui pourrait être refactorisé.

Les constructions de flux de contrôle de niveau supérieur ont tendance à correspondre aux concepts du domaine problématique. Un if / else est une décision basée sur une condition. Une boucle indique d'effectuer une action à plusieurs reprises. Même une déclaration de rupture dit "nous faisions cela à plusieurs reprises, mais maintenant nous devons arrêter".

Une instruction goto, d'autre part, tend à correspondre à un concept dans le programme en cours d'exécution, pas dans le domaine problématique. Il dit de continuer l'exécution à un point spécifié du programme . Quelqu'un qui lit le code doit déduire ce que cela signifie par rapport au domaine problématique.

Bien sûr, toutes les constructions de niveau supérieur peuvent être définies en termes de gotos et de branches conditionnelles simples. Cela ne signifie pas qu'ils ne sont que des gotos déguisés. Considérez-les comme des gotos restreints - et ce sont les restrictions qui les rendent utiles. Une instruction break est implémentée comme un saut à la fin de la boucle englobante, mais il vaut mieux la considérer comme opérant sur la boucle dans son ensemble.

Toutes choses étant égales par ailleurs, le code dont la structure reflète celle du domaine problématique a tendance à être plus facile à lire et à maintenir.

Il n'y a aucun cas où une instruction goto est absolument requise (il y a un théorème à cet effet), mais il y a des cas où cela peut être la moins mauvaise solution. Ces cas varient d'une langue à l'autre, selon les constructions de niveau supérieur prises en charge par la langue.

En C, par exemple, je pense qu'il y a trois scénarios de base où un goto est approprié.

1. Sortir d'une boucle imbriquée. Cela ne serait pas nécessaire si la langue avait une instruction break étiquetée.
2. Renvoi d'un bout de code (généralement un corps de fonction) en cas d'erreur ou autre événement inattendu. Cela ne serait pas nécessaire si le langage comportait des exceptions.
3. Implémentation d'une machine à états finis explicite. Dans ce cas (et, je pense, seulement dans ce cas), un goto correspond directement à un concept dans le domaine problématique, passant d'un état à un autre état spécifié, où l'état actuel est représenté par le bloc de code en cours d'exécution. .

D'un autre côté, une machine à états finis explicite peut également être implémentée avec une instruction switch dans une boucle. Cela présente l'avantage que chaque état commence au même endroit dans le code, ce qui peut être utile pour le débogage, par exemple.

L'utilisation principale d'un goto dans un langage raisonnablement moderne (celui qui prend en charge if / else et les boucles) est de simuler une construction de flux de contrôle qui manque dans le langage.

Cela dépend sûrement du langage de programmation. La principale raison gotoa été controversée en raison de ses effets néfastes qui surviennent lorsque le compilateur vous permet de l'utiliser trop généreusement. Des problèmes peuvent survenir, par exemple, s'il vous permet d'utiliser gotode telle manière que vous pouvez maintenant accéder à une variable non initialisée, ou pire, pour sauter dans une autre méthode et jouer avec la pile d'appels. Il devrait être de la responsabilité du compilateur de refuser le flux de contrôle absurde.

Java a tenté de «résoudre» ce problème en l'interdisant gotoentièrement. Cependant, Java vous permet d'utiliser à l' returnintérieur d'un finallybloc et donc d'avaler une exception par inadvertance. Le même problème est toujours là: le compilateur ne fait pas son boulot. La suppression gotode la langue ne l'a pas corrigé.

En C #, gotoest aussi sûr que break, continue, try/catch/finallyet return. Il ne vous permet pas d'utiliser des variables non initialisées, il ne vous permet pas de sortir d'un bloc finally, etc. Le compilateur se plaindra. C'est parce qu'il résout le vrai problème, qui est comme je l'ai dit le flux de contrôle absurde. goton'annule pas comme par magie l'analyse d'affectation définitive et d'autres vérifications raisonnables du compilateur.

Oui. Lorsque vos boucles sont imbriquées à plusieurs niveaux, gotoc'est le seul moyen de sortir élégamment d'une boucle intérieure. L'autre option consiste à définir un indicateur et à sortir de chaque boucle si cet indicateur remplit une condition. C'est vraiment moche et assez sujet aux erreurs. Dans ces cas, gotoc'est tout simplement mieux.

Bien sûr, la breakdéclaration étiquetée de Java fait la même chose, mais sans vous permettre de sauter à un point arbitraire dans le code, ce qui résout proprement le problème sans autoriser les choses qui font le gotomal.

La plupart du découragement vient d'une sorte de "religion" qui a été créée autour de Dieu Djikstra qui était convaincante au début des années 60 à propos de son pouvoir aveugle de:

• sauter n'importe où dans n'importe quel bloc de code
  • fonction non exécutée depuis le début
  • boucles non exécutées depuis le début
  • initialisation de variable ignorée
• sauter loin de n'importe quel bloc de code sans aucun nettoyage possible.

Cela n'a plus rien à voir avec l' gotoénoncé des langages modernes, dont l'existence est simplement due à soutenir la création de structures de code autres que celles fournies par le langage.

En particulier, le premier point principal ci-dessus est plus autorisé et le second est nettoyé (si vous gotosortez d'un bloc, la pile est déroulée correctement et tous les destructeurs appropriés sont appelés)

Vous pouvez vous référer à cette réponse pour avoir une idée de la façon dont même le code n'utilisant pas goto peut être illisible. Le problème ne vient pas de lui-même, mais de sa mauvaise utilisation.

Je peux écrire un programme entier sans utiliser if, juste for. Bien sûr, ce ne sera pas bien lisible, un look maladroit et inutilement compliqué.

Mais le problème n'est pas for. C'est moi.

Des choses comme break, continue, throw, bool needed=true; while(needed) {...}, etc. sont faisant remarquer plus de Masquerade goto pour échapper à l' écart des cimeterres des zélotes Djikstrarian, que -50 ans après l'invention de laguages- modernes veulent toujours leurs prisonniers. Ils ont oublié de quoi Djikstra parlait, ils ne se souviennent que du titre de sa note (GOTO considéré comme nuisible, et ce n'était même pas son nouveau titre: il a été modifié par l'éditeur) et blâmer et bash, bash et blâmer chaque contructure ayant ces 4 lettre placée dans l'ordre.

Nous sommes en 2011: il est temps de comprendre que le gotofait de tenir compte de la GOTOdéclaration de Djikstra était convaincant.

Le goto impair ici ou là, tant qu'il est local à une fonction, nuit rarement de manière significative à la lisibilité. Il en profite souvent en attirant l'attention sur le fait qu'il se passe quelque chose d'inhabituel dans ce code qui nécessite l'utilisation d'une structure de contrôle quelque peu inhabituelle.

Si les gotos (locaux) nuisent considérablement à la lisibilité, cela signifie généralement que la fonction contenant le goto est devenue trop complexe.

Le dernier goto que j'ai mis dans un morceau de code C était de construire une paire de boucles de verrouillage. Il ne rentre pas dans la définition normale de l'utilisation «acceptable», mais la fonction est finalement devenue beaucoup plus petite et plus claire. Pour éviter le goto, il aurait fallu une violation particulièrement désordonnée de DRY.

Je pense que toute cette question a consisté à aboyer le mauvais arbre.

GOTO en tant que tel ne me semble pas problématique, mais il s'agit plutôt très souvent d'un symptôme d'un véritable péché: le code spaghetti.

Si le GOTO provoque un croisement majeur des lignes de contrôle de flux, alors c'est mauvais, point final. S'il ne traverse aucune ligne de contrôle de débit, il est inoffensif. Dans la zone grise entre les deux, nous avons des choses comme les renflouements de boucle, il y a encore des langages qui n'ont pas ajouté de constructions qui couvrent tous les cas gris légitimes.

Le seul cas où je me suis retrouvé à l'utiliser effectivement depuis de nombreuses années est le cas de la boucle où le point de décision est au milieu de la boucle. Vous vous retrouvez avec un code en double, un drapeau ou un GOTO. Je trouve que la solution GOTO est la meilleure des trois. Il n'y a pas de croisement de lignes de contrôle de flux ici, c'est inoffensif.

Oui, le goto peut être utilisé pour bénéficier de l'expérience du développeur: http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/

Cependant, comme pour tout outil puissant (pointeurs, héritage multiple, etc.), il faut être discipliné en l'utilisant. L'exemple fourni dans le lien utilise PHP, ce qui limite l'utilisation de la construction goto à la même fonction / méthode et désactive la possibilité de sauter dans un nouveau bloc de contrôle (par exemple, boucle, instruction switch, etc.)

Dépend de la langue. Il est encore largement utilisé dans la programmation Cobol, par exemple. J'ai également travaillé sur un appareil Barionet 50, dont le langage de programmation du micrologiciel est un ancien dialecte BASIC qui, bien sûr, vous oblige à utiliser Goto.

Je dirais non. Si vous trouvez la nécessité d'utiliser GOTO, je parie qu'il est nécessaire de repenser le code.

gotopeut être utile lors du portage du code assembleur hérité vers C. Dans un premier temps, une conversion instruction par instruction en C, en gotoremplacement de l' branchinstruction assembleur , peut permettre un portage très rapide.

Je dirais non. Ils doivent toujours être remplacés par un outil plus spécifique au problème que le goto est utilisé pour résoudre (sauf s'il n'est pas disponible dans votre langue). Par exemple, les instructions break et les exceptions résolvent les problèmes précédemment résolus de fuite de boucle et de gestion des erreurs.