Goto, une instruction pas comme les autres

Citation:

---

Envoyé par germinolegrand

Je mettrais plutôt ça sur le compte du dogmatisme faramineux qui sous-tend les communautés de ces langages, plus promptes à sortir leurs fameux Design Patterns que des solutions sur mesure. Alors que (et c'est très amusant de mon point de vue) un simple goto solutionnerait un des plus gros problèmes du Java (ils se plaignent de pas pouvoir revenir au début de leur try s'il a échoué... :mrgreen:).

---

Là en l’occurrence ton goto jouerait le même rôle qu’une bête boucle, je ne vois pas ce qu’il apporterait de plus dans ce contexte précis (autant je peux concevoir son intérêt dans x boucles imbriquées, afin d’éviter de se farcir la palanquée de break et de contrôles, mais là pour un simple schéma de retry je ne suis pas convaincu).

Sinon je te l’accorde, je ferais aussi parti de ceux qui se tourneraient vers ce genre de solution plutôt que d’utiliser des choses plus "terre à terre". C’est peut-être inconscient =P

Il m'arrive d'utiliser un GOTO en Transaq-SQL quand je fais une procédure stockée et que je ne souhaite pas faire de sous-procédures

On est là dans un cas particulier :
- le programme court (pas plus d'une centaine de lignes)
- le langage a un domaine assez limité (orienté uniquement sur la manipulation de tables)

du coup le GOTO reste lisible et facilement débugable.

s'il n'y avait pas de GOTO, alors il me faudrait utiliser un enchaînement de IF BEGIN END ELSE IF BEGIN .... ce qui est dur à lire.
le goto qui pointe sur des étiquettes bien claires, ça peut être pas mal !

à l'inverse, en Java, même si le goto était possible, je ne l'utiliserai pas pour des raisons de lisibilité.

ça peut aider dans une volonté d’obfuscation.

Bonjour à tous,

Je suis un amateur, j'ai commencé à écrire de petits programmes personnel avec un ORIC en 1983... aujourd’hui j'utilise Windev.
Le souvenir que je garde des instructions GOTO sous Basic, c'est qu'elles se trouvaient dans le programme principal qui s'exécutait linéairement et qu'elles permettaient un branchement à une ligne précise.
Aujourd’hui avec le procédural, c'est les appels aux fonctions et autres procédures qui font le boulot et GOTO n'a plus d'intérêt... me semble-t'il.
Du reste, il aura fallut que je tombe sur la question posée dans ce forum, pour que je me demande si l'instruction GOTO intègre Windev... oui c'est le cas, mais je ne l'ai jamais utilisée.
Maintenant, c'est vous qui voyez...

Bon dev.

Bonjour,

cela faisait longtemps aussi que je n'avait répondu à un fil sur le goto !
Après m'être frotté avec des machines allant du TI99/4A à l'atari 512stf, J'ai enfin reçu une «vraie» formation informatique en fac au courant des années 1990. C'est à ce moment qu'on m'a révélé les commandements que je ne devrais jamais violer au risque de m'exposer à la colère divine. Je peux citer des choses comme «la bande passante du réseau illimitée tu ne croiras point» ou «de courtes fonctions tu écriras» sans oublier le «ton code tu commenteras». Mais il est vrai que LA loi première était «JAMAIS de goto tu n'utiliseras», LA loi qui évite de rentrer dans un état de péché originel ... le goto est comme une pomme qu'il ne faut pas croquer sous peine d'expulsion du jardin de l'Eden de la programmation structurée.
J'obéissais militairement à ces lois dans le but d'être adoubé mais essayais néanmoins d'en comprendre l'origine. Jusqu'au jour où j'ai reçu l'illumination de la part d'un de mes professeur, M. Cansell (true story).

Le goto peut introduire de la confusion dans la phase de compilation, il interrompt le flux sans qu'on puisse a priori savoir ce qui va se passer réellement ou quelle était l'intention du programmeur (du moins à l'époque). Écrire une boucle for en utilisant des gotos masquait le fait de vouloir utiliser une boucle for et empêchait le compilo de faire du bon boulot. C'est pourquoi il était préférable de toujours utiliser une boucle for ou while, ou toute autre structure de plus haut niveau pour se passer de goto. Enfin en général, car les gurus du goto pouvaient optimiser certains codes grâce à eux, mais comme nous ne sommes que des mortels faillibles et non des gurus ....
Et effectivement, au fur et à mesure, les cas d'utilisation de goto se sont retrouvées de moins en moins nombreux car remplacés par de nouvelles structure de niveau supérieur : switch (goto calculé), gestion des erreurs, etc ...
La règle est alors amendée : si le langage utilisé ne propose pas la structure de contrôle adaptée alors le goto avec des pincettes tu pourras utiliser. Par exemple le C ne propose pas de gestion d'erreur par try/catch ... ok on peut utiliser les goto si c'est indispensable, C ne propose pas un «ne fait pas ça pour au premier tour de boucle» du coup un goto est «autorisé» et même élégant dans ce cas je trouve car ça évite une duplication de code (encore une loi ... jamais inutilement du code tu ne dupliqueras).

Le second point est, comme le soulève Obsidian, celui des automates finis, et plus généralement des parsers. Les machines à états avec transitions s'implémentent agréablement avec des gotos ... mais souvent la taille des programmes est telle que le code devient complexe sans pour autant être compliqué. La solution la plus simple est donc de créer un programme (et de prouver qu'il est correct) qui va s"en charger pour nous. Lex,flex,bison et yacc tirent leur origine de ça et créent du code bourré de goto (enfin dans les années 90...) tout à fait correct (la plupart du temps dans les années 90:) ).

Bref, un goto c'est comme une paire de ciseaux pointus : on se blesse plus souvent qu'avec une paire de ciseaux arrondis.

Citation:

---

Envoyé par picodev

Bref, un goto c'est comme une paire de ciseaux pointus : on se blesse plus souvent qu'avec une paire de ciseaux arrondis.

---

Mais les meilleurs artisans n'oublient jamais qu'ils ont dans leur boîte à outils une paire de ciseaux pointus pour s'adapter précisément à leurs besoins :).
Le plus grand danger c'est de ne pas connaître les outils à sa disposition, et pire, d'en avoir peur :(.

Bonjour,

Le goto est très utilisé en programmation kernel :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

void foo(void) { char * ptr = kalloc(sizeof(char) ); if( ! ptr ) goto END; // blabla char * ptr2 = kalloc(sizeof(char) ); if( ! ptr2) goto FREE_PTR1;     free(ptr2); FREE_PTR1 : free(ptr); END : // blabla }

---

Ils permettent d'être sûr que toutes les ressources sont bien libérées à la fin de la fonction.
Bon là je n'ai qu'un exemple "bateau".

L'exemple donné par Obsdian http://www.developpez.net/forums/d14...tion-autres/#4
ne me semble pas très heureux: j'écrirai plutôt ceci:

Code:

---

1 2 3 4

for (x = 1; x < 5; x++) { printf ("%d-",x); } printf ("%d" ,x++);

---

Entrer au milieu d'une boucle est interdit en Fortran pour une raison simple: il est très facile de ne pas initialiser correctement cette boucle, et si la boucle comporte de nombreuses lignes, il n'est pas naturel de remonter loin en avant pour le vérifier.

Bien sûr, le goto est bien utile dans certains cas (je n'hésite pas à l'utiliser, c'est faire preuve de sectarisme que de s'y refuser)
[TROLL]
mais pour obscurcir un code, rien ne vaut le COMEFROM http://en.wikipedia.org/wiki/Comefrom
[/TROLL]

Citation:

---

Envoyé par Neckara

Le goto est très utilisé en programmation kernel :

...

Ils permettent d'être sûr que toutes les ressources sont bien libérées à la fin de la fonction.
Bon là je n'ai qu'un exemple "bateau".

---

Ce n'est pas tant lié à la programmation kernel qu'à la gestion d'erreur en C (et c'est d'ailleurs cité dans le premier message).

Un cas rigolo rencontré en stage où j'ai pas trouvé de solution (propre) hors GOTO.

Code:

---

1 2 3 4 5 6 7 8 9 10

while(test){ // des lignes de code if(test2) GOTO Label //des lignes de code //fin du while } // d'autres lignes de code Label :   }

---

En combinant un break dans la boucle, et un if en sortie de boucle on peut éviter le GOTO, mais ça complique inutilement l'algo.

Ou alors ton while est inclus dans une fonction, et tu fais un return dans le if au lieu du goto !

Car si ton while est épais, ou est réutilisé souvent, c'est mieux de le sortir ! :)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

int fun(...) { while(test) { // des lignes de code if(test2) return (42); //des lignes de code //fin du while } }   void autre_fun(...) { fun(); // d'autres lignes de code //label: }

---

@Metalman : tu sembles tomber exactement dans le "je n'utilise pas de goto par principe". Si la boucle est réutilisée, OK pour le mettre dans une fonction. Si elle ne l'ai pas, goto totalement acceptable (et limite je trouve mieux).

Citation:

---

Envoyé par ManusDei

Un cas rigolo rencontré en stage où j'ai pas trouvé de solution (propre) hors GOTO.

Code:

---

1 2 3 4 5 6 7 8 9 10

while(test){ // des lignes de code if(test2) GOTO Label //des lignes de code //fin du while } // d'autres lignes de code Label :   }

---

En combinant un break dans la boucle, et un if en sortie de boucle on peut éviter le GOTO, mais ça complique inutilement l'algo.

---

Dans ce scénario je suis d’accord avec toi, c’est beaucoup moins verbeux d’opter pour un goto que d’ajouter un troisième test (et sa variable) afin de déterminer si les lignes après la boucle doivent être évaluées ou non (ce serait se "compliquer" la vie, je te l’accorde).

Maintenant je me pose la question de la lisibilité de tout ça dans un cas réel (où on n’a pas seulement affaire à quatre lignes) ; là où justement un code verbeux mettra en évidence le test post-boucle, ton code demandera certainement plus d’effort de lecture (à fortiori pour quelqu’un qui n’a pas écrit le code) : « Tiens un label ! Attend, mais du coup la boucle et les lignes qu’il y a juste au-dessus sont exécutées ? Bon, je vais chercher où est-ce qu’on se sert de ce label... à ben oui, c’est dans la boucle. Ok, donc on passe bien dans la boucle mais on n’exécute pas systématiquement les lignes qu’il y a juste après... Ok, get it, je peux passer à la suite »

J'ai édité mon post pour que l'on voit mieux LA phrase qui était écrite "avant" le code et "après" la 1ère remarque...

...et I_pnose a remonté le vrai : personne ne fait de goto... on en voit un, on perd ses moyens....

Citation:

---

Envoyé par germinolegrand

... (et c'est très amusant de mon point de vue) un simple goto solutionnerait un des plus gros problèmes du Java (ils se plaignent de pas pouvoir revenir au début de leur try s'il a échoué... :mrgreen:).

---

C'est moche mais ça se code : (sans goto)

Code:

---

1 2 3 4 5 6 7 8 9

boolean valide; do { try { valide = false; //code ici } catch (Exception e) { valide = true; } } while (valide); }

---

Citation:

---

Envoyé par Bktero

@Metalman : tu sembles tomber exactement dans le "je n'utilise pas de goto par principe". Si la boucle est réutilisée, OK pour le mettre dans une fonction. Si elle ne l'ai pas, goto totalement acceptable (et limité je trouve mieux).

---

Les fonctions sont bien, par principe car on peut faire des tests fonctionnels.

Citation:

---

Envoyé par I_Pnose

Maintenant je me pose la question de la lisibilité de tout ça dans un cas réel (où on n’a pas seulement affaire à quatre lignes) ; là où justement un code verbeux mettra en évidence le test post-boucle, ton code demandera certainement plus d’effort de lecture (à fortiori pour quelqu’un qui n’a pas écrit le code) : « Tiens un label ! Attend, mais du coup la boucle et les lignes qu’il y a juste au-dessus sont exécutées ? Bon, je vais chercher où est-ce qu’on se sert de ce label... à ben oui, c’est dans la boucle. Ok, donc on passe bien dans la boucle mais on n’exécute pas systématiquement les lignes qu’il y a juste après... Ok, get it, je peux passer à la suite »

---

Les break ( y compris dans le switch case ), continue et les fonctions vont dans ce sens et c'est pour cela que les goto sont à proscrire sauf cas exceptionnels ( pourquoi pas de break N en C :koi: ? ).

Citation:

---

Envoyé par valkirys

Les fonctions sont bien, par principe car on peut faire des tests fonctionnels.

---

Lorsqu'elles n'ont pas de responsabilité clairement définies et pas de sens par elles-mêmes (i.e. quand une fonction est créée juste pour respecter une règle quelconque : nombre de lignes, pas de goto), elles ne sont pas bien et ne permettent pas de faire des tests fonctionnels dessus (tout simplement car elles ne sont pas une fonctionnalité).

Commençons par réfléchir aux responsabilités, aux rôles des différentes fonctions, à l'objectif à atteindre plutôt que de se focaliser sur telle ou telle règle arbitraire. On aboutit à de bien meilleurs résultats (et ces règles sont naturellement respectées dans l'immense majorité des cas, sauf quand elles nuisent plus qu'autre chose).

Citation:

---

Envoyé par Metalman

J'ai édité mon post pour que l'on voit mieux LA phrase qui était écrite "avant" le code et "après" la 1ère remarque...

---

Dans ce cas, ce n'est pas une question de goto.

+1 pour gl !

Citation:

---

Envoyé par gl

Lorsqu'elles n'ont pas de responsabilité clairement définies et pas de sens par elles-mêmes (i.e. quand une fonction est créée juste pour respecter une règle quelconque : nombre de lignes, pas de goto), elles ne sont pas bien et ne permettent pas de faire des tests fonctionnels dessus (tout simplement car elles ne sont pas une fonctionnalité).

Commençons par réfléchir aux responsabilités, aux rôles des différentes fonctions, à l'objectif à atteindre plutôt que de se focaliser sur telle ou telle règle arbitraire. On aboutit à de bien meilleurs résultats (et ces règles sont naturellement respectées dans l'immense majorité des cas, sauf quand elles nuisent plus qu'autre chose).

---

Je n'ai pas dis le contraire, et c'est bien de rappeler tout cela. Le fait est que si l'on pense le code avec des fonctions pour des tests on évitera la majorité des goto.

Comme toujours on passe d'une extrême à l'autre

Dans les langages anciens tel le basic ou le COBOL, l'emploi intempestif du GOTO rendait les programmes peu compréhensibles donc difficilement maintenables. Dans les langages plus récents, les structures de contrôles ont permis d'éviter, dans la plupart des cas, l'emploi du GOTO.

Cependant s'interdire par intellectualisme l'emploi du GOTO relève de la stupidité. En cas d'algorithme complexe, cette instruction peut s'avérer utile voire nécessaire.

En fait le débat ne s’arrêtera jamais.
il y a des gens qui sont allergiques à goto et ne veulent/peuvent pas comprendre une argumentation qui montre qu'on peut l'utiliser.
Personnellement je sors de ce débat. J'ai appris qu'un outil peut tuer, et ce qui est important c'est de savoir s'en servir plutôt que de le supprimer.

je vais tranquillement continuer à utiliser mes goto (sur 100 fichiers source moins de 10 ont des goto) quand le besoin se fait sentir et ignorer ceux qui critiquent sans réfléchir parce qu'on leur a dit que c'est le mal ou qu'ils le pensent vraiment eux-même.