Discussion :

[bibilolo2]

Selon Peter Aitken et Bradley Jones:

Quand un programme exécute un branchement après une instruction goto, il ne garde aucune trace de l'emplacemet d'où il vient et l'ordre d'exécution va vite se compliquer. C'est ce que l'on appelle du code spaghetti.

[souviron34]

eh bien moi j'utilisais comme un forcené les GOTO en FORTRAN, car c'était la norme des programmes scientifiques, au début des années 80.

Les gros codes FORTRAN existants encore (librairie maths du CERN, modèles numériques) resteront tel quels, car personne ne les ré-écrira (de 20 à 30 ans de test opérationnel et +20 millions de lignes de code, ça se refait pas..).

Par contre, depuis 17 ans que je fait du C, et sur de très gros projets complexes (> 1 million de lignes de code) (au total plus de 2 millions de ligne de code), je n'ai JAMAIS utilisé un seul GOTO..

Effectivement le point central est la maintenance : il est extrémement difficile et long de relire et "formaliser" un code avec des sauts. Déjà c'est diffcile en Fortran avec les formats numérotés. Mais en plus avec les goto...

De plus, certaines normes pour certains types de projets (les projets de la NASA par exemple), en interdisent formellement l'usage.

Mais c'est principalement que c'est une autre manière de penser. Et bien sûr que l'assembleur fait des JMP. Mais ce pourquoi on a inventé des langages de programmation c'est justement pour pas être au niveau de la machine, mais au niveau conceptuel.....

[gl]

Là c'est vraiment particulier mais dans certaines circonstances mieux vaut ne pas faire autrement à mon avis

Dans cet exemple particulier, l'interet du goto est, si j'ai bien compris, d'executer dans le if() le meme code que dans un des case. Personellement, j'aurais plutot ecrit une fonction effectuant ce traitement et appele la fonction dans le if et dans le case.

[Emmanuel Delahaye]

J'apporte mon grain de sel, y'a pas de raison

A mon avis le principal reproche qu'on peut faire au goto (et à raison), c'est de casser l'aspect structuré du code, et surtout permettre des sauts en arrière, ce qui crée un flux programmatique qui se croise, le fameux "spaghetti code". Mais alors que dire des break, des continue, des return lorsqu'ils ne sont pas en fin de fonction ? Que dire même des switch ?

La portée des break et des continue est définie (bloc de structure de code). Avec un goto, c'est plus flou et on peut sortir brutalement d'une structure de code. Quand aux return multiples, je les combat aussi ardemment que les goto sauvages.

L'usage du goto se justifie dans deux cas bien précis :

Permier cas, traitement d'erreur. Exemple :

Ok.

Deuxième cas, pouvoir sortir rapidement d'une construction très complexe et remonter une erreur.

Eventuellement, mais une variable 'err' bien gérée (0 = OK, non 0 = ERR) est très simple à intégrer dans les conditions des structures de code.

Je pense que tout le monde est d'accord pour dire 'le goto injustifié c'est mal tant qu'il existe une alternative simple et viable'. Ce discours s'adresse surtout aux débutants, afin de les inciter à utiliser les structures de codes qui couvrent 100% des cas. Ensuite, si on veut simplifier certains traitement 'exceptionnels', peut être. Mais il est certain que l'on peut toujours s'en passer.

[amaury pouly]

Dans cet exemple particulier, l'interet du goto est, si j'ai bien compris, d'executer dans le if() le meme code que dans un des case. Personellement, j'aurais plutot ecrit une fonction effectuant ce traitement et appele la fonction dans le if et dans le case.

Je ne l'ai pas fait car cette fonction est appelée trop souvent et puis que le traitement n'est pas très long(3-4 lignes) . Certes on aurait pû inliner mais pour moi çà n'en valait pas la peine .
D'ailleurs dans cette structure il y avait d'autres cas qui rammenaient au cas.
Néanmoins c'est exceptionnel comme utilisation .

[bpy1401]

les gotos permettent de casser la structure logicielle. Typiquement, on peut faire des trucs comme ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
int Fct1(int Param)
{
   int ReturnValue;
   if (Param)
   {
      goto Toto;
      ReturnValue=1;
   }
   else
   {
      ReturnValue=2;
   }
 
Toto:
  return (ReturnValue);
}

Ici c'est facile, on a généré au beau bug facilement visible, mais parfois l'algorithme est plus complexe, et on ne voit pas ce type d'erreur.

Structurer correctement son logiciel permet de le rendre plus robuste, et plus facile à maintenir.
Si des normes d'écritures en langage C on dit qu'il ne fallait surtout pas l'utiliser, ce n'est pas pour rien.

A+

[lakitrid]

Personnelement je n'ia utilisé les goto que dans un domaine :
La programmation noyau Linux. Au début j'étais réticent à utiliser le Goto, mais au final, s'il est correctement utiliser il peut aider à la lisibilité du code.
J'utilisais donc le goto toujours en descendant pour la gestion des erreurs
par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
res0=...;
if(!res1)
   goto err1;
<...>
if(!res2)
   goto err2;
<...>
err1:
   free(res0);
err2:
   free(res1);
<...>
   return;

il est clair qu'il est toujours possible de faire sans, mais si on cadre bien son emploi, on peut alleger le code sans perdre en lisibilité et même en gagner un peu avec justement l'allegement du code.

[tof_justice]

Je cite "Méthodologie de la programmation en C" de Jean Pierre Braquelaire , une référence dans le domaine de la prog !!! Mon mentor !! Un ancien prof de la fac il y a longtemps...

"

Le branchement est à utiliser avec la plus grande prudence. Cependant, il est parfois utile pour simuler des échappements non implémentés en C (essentiellement la sortie de plusieurs boucles imbriquées).

On ne doit l'utiliser seulement si les intrusctions break et continue sont insuffisantes. Par exemple, on ne peut, avec l'instruction break, sortir d'une boucle qui se trouve dans un aiguillage imbriqué dans la boucle. Dans ce cas, Break permet seulement de sortir de l'aiguillage.

La sortie de plusieurs boucles imbriquées est également un cas que l'on ne peut gérer avec un échappement. C'est le cas de l'exemple suivant, présentant le parcours d'une liste de listes avec arrêt sur le premier élément vérifiant une condition donnée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
                 for (jour = 0; jour < 7; jour++)
                        for (heure = 1; heure < 24; heure++)
                             if (semaine[jour][heure]<semaine[jour][heure-1])
                             goto baisse;
                baisse:

On peut éviter ici l'utilisation du branchement en plaçant l'instruction dans
une fonction, dont on sort au moyen d'un return :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
void recherche(int *j, int *h)
{
    int jour, heure;
    for (jour = 0; jour < 7; jour++)
          for (heure = 1; heure < 24; heure++)
               if (semaine [jour] [heure] <Semaine [jour] [heure-1])
                  {
                    *j = jour;
                    *h = heure;
                    return;
                   }     
    *j = jour;
    *h = heure;
}

Cependant, la gestion des paramètres par référence alourdit l'écriture et entraîne une duplication de code. Il est plus préférable d'écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
void recherche(int *j, int *h)
{
    int jour, heure;
    for (jour = 0; jour < 7; jour++)
          for (heure = 1; heure < 24; heure++)
               if (semaine[jour][heure]<semaine[jour][heure-1])
               goto fin_de_boucle;
 
    fin_de_boucle:
    *j = jour; 
    *h = jour;
}

Une autre utilisation classique du saut est la gestion d'erreurs, avec interruption du traitement (goto erreur) ou reprise (goto début). Tous ces
exemples d'utilisation du branchement sont construits sur le même modèle: la sortie de plusieurs blocs imbriqués. Il est par contre préférable d'éviter d'utiliser un goto pour se déplacer dans un bloc ou pour rentrer dans un bloc de profondeur inférieure.

cela devrait clore un éternel débat qui n'a plus lieu d'être !!!

[akoril]

Salut,

Moi non plus j'aime pas les goto... il fut un temps où je les virais... Pourtant y'a pas que lui qui n'est pas structuré :
Mais dans un switch() case: break...
le break est un goto comme le continue dans un while() ou for(;

Souvent en virant un goto (mis par qq d'autre ), j'ai rendu le code moins joli (question de goût) mais je préfère...

v'la question de goût et d'expérience...

[Thierry Chappuis]

Moi non plus j'aime pas les goto... il fut un temps où je les virais... Pourtant y'a pas que lui qui n'est pas structuré :
Mais dans un switch() case: break...

Je trouve tout de même une instruction switch beaucoup plus structurée qu'un goto. Contrairement au goto, je ne trouve pas qu'elle nuit à la lisibilité du code. Perso, je n'ai jamais utilisé la possibilité offerte par goto.

Meilleures salutations

Thierry

[Jack_serious]

Moi non plus j'aime pas les goto... il fut un temps où je les virais... Pourtant y'a pas que lui qui n'est pas structuré :
Mais dans un switch() case: break...

Je trouve tout de même une instruction switch beaucoup plus structurée qu'un goto. Contrairement au goto, je ne trouve pas qu'elle nuit à la lisibilité du code. Perso, je n'ai jamais utilisé la possibilité offerte par goto.

Meilleures salutations

Thierry

Idem, je n'ai plus utilise un seul goto depuis le temps ou je programmais en Basic sur ma calculatrice sur les bancs du lycee... (aaah les cours de physique).
Et je m'en porte tres bien.

[akoril]

OK pour le Goto, ce n’est pas beau…

Mais quand on parle de structure (voir réponse de Vic sur les break, continue, return…) je suis entièrement d’accord… et donc ce n’est pas la seule réponse pour ne pas utiliser le Goto.

Le seul langage qui respecte le flux de programmation… c’est le Lisp et ces dérivés… Pratiquez-le un peu (et même beaucoup) et vous connaîtrais les contraintes d’un respect des flux…

[Thierry Chappuis]

Le seul langage qui respecte le flux de programmation… c’est le Lisp et ces dérivés… Pratiquez-le un peu (et même beaucoup) et vous connaîtrais les contraintes d’un respect des flux…

Un code C bien structuré qui n'utilise pas de goto et qui n'abuse pas de la compilation conditionnelle respecte à mon sens relativement bien le flux de programmation. Qu'est-ce que Lisp a de plus à ce niveau? J'ai beaucoup de problème avec la synthaxe du LISP (et j'ai très peu d'expérience en programmation fonctionnelle), mais c'est vrai que je ne me suis pas acharné non plus. Je vais étudier cela de plus près.

Meilleures salutations

Thierry

[ogenki]

La regle : Pas de goto dans un programme

La valeur d'un programmeur est inversement proportionnel au nombre de goto que l'on trouve dans son code

Pour clarifier ton programme Utilise les sous programmes avec les commentaire qui vont bien

entierement d'accord avec cette regle goto est une aberation..

[Tellmarch]

bon dsl j'ai pas tout lu donc ça a peut etre deja été dit, mais il y a toujours l'argument d'autorité :

Dijkstra a dit que goto c'est mal :
http://www.acm.org/classics/oct95/

Et moi je lui fait confiance

[Thierry Chappuis]

Dijkstra a dit que goto c'est mal :
http://www.acm.org/classics/oct95/

Et moi je lui fait confiance

Ca c'est tout de même limité comme réflexion. Il faut se méfier des gourous et de leurs dogmes. En l'occurence, tu fais bien de lui faire confiance.

Thierry

[Tellmarch]

hm c'est pas si limité que ça, Dijkstra est un chercheur connu, et je m'appuis sur ses résultats... c'est une démarche courante

[Thierry Chappuis]

C'était juste la façon dont tu l'a dit! Je ne met pas en doute ses dires, d'autant plus que je suis d'accord.

Salutations

Thierry

[albokos]

Personellement j trouve que goto est indique pour resoudre uncertain nombre de problemes et notament ceux de saut d'instruction et j ne comprend pas non plus pourquoi elle sucite tant de crainte. une fois qu'on sait comment ca marche ce n'est plus du tou illisible je trouve.

[zerocoolyoussef]

je pense su'on doit profiter des avantages de la programmation structuré et ne pas abusé des goto.Car sutout pr les gens qui ont deja programmer en assembleur on peut simuler des tests des boucles jsute avec les gotos et le code et ne pas du tout claire et s'est en plus en plus difficile pr le maintenir ou le corriger.