Discussion :

[fearyourself]

Disons, que dans la theorie, le goto peut-etre utilise mais il est rare qu'il soit necessaire ou qu'il soit meme souhaitable. Son utilisation rend l'algorithme difficilement comprehensible par un oeil externe (pareil que pour le break ou le continue) et cela donne souvent du code spaghetti (qui va dans tous les sens)

Je le deconseille...

[Trap D]

Si je ne me trompe pas, un mathématicien a démontré qu'on pouvait en toute occasion se passer du goto. Ceci dit, pour se sortir d'un imbrication de boucle ça peut-être utile, mais c'est en général (99,99 % des cas) le signe d'une (très) mauvaise analyse/conception de l'algorithme.

[Rémiz]

Disons qu'il faut l'utiliser avec modération.

Dans les boucles, il peut être utilisé à la place du break. Personellement je trouve que :

Code :

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

1
2
3
for(x=0; x<100; x++)
    if (val == tab[x])
        goto FinRecherche

est plus parlant que :

Code :

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

1
2
3
for(x=0; x<100; x++)
    if (val == tab[x])
        break;

[Edouard Kaiser]

Dans ce cas à la place du "for" autant faire un "while" est on évite encore ces break ou goto assez moche

[diogene]

Rémiz :

Code :

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

1
2
3
for(x=0; x<100; x++) 
    if (val == tab[x]) 
        goto FinRecherche

Personnellement, je n'aime pas. Pas tellement à cause du goto de ce code mais à cause de la présence d'un label FinRecherche , car on ne sait pas sans TOUT lire à partir de quel(s) endroit(s) du code on peut arriver là.
fearyourself :

Son utilisation rend l'algorithme difficilement comprehensible par un oeil externe (pareil que pour le break ou le continue)

Oui, mais au moins, avec break ou continue, on sait dans quelle direction du code se trouve la suite. Et le code est du type spaghetti mais peigné

[Franck.H]

Moi perso, en plus de deux ans de C, jamais utilisé de goto ou de jmp

[Rupella]

Les standards de l'industrie imposent comme règle de ne jamais
utiliser de goto !

Se référer aux règles MISRA par exemple...
Après, faut voir si il faut rester dans l'amateurisme...

[Alexis75014]

Je m'en suis servi à quelque reprise lorsque je dévellopais autour du noyau linux, en mode kernel par exemple. Par contre pour un programme utilisateur je ne vois pas pourquoi utiliser un goto.

Je suis certainement trop limité pour comprendre.

[Pirlouit260593]

Disons qu'il faut l'utiliser avec modération.

Dans les boucles, il peut être utilisé à la place du break. Personellement je trouve que :

Code :

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

1
2
3
for(x=0; x<100; x++)
    if (val == tab[x])
        goto FinRecherche

est plus parlant que :

Code :

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

1
2
3
for(x=0; x<100; x++)
    if (val == tab[x])
        break;

Pour ces codes, je préfère écrire de la façon suivante qui est plus lisible, plus parlant et plus concise.

Code :

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

for(x=0; x<100 && val != tab[x]; x++);

En fait en regardant bien les deux codes, on voit bien qu'il ne s'agit pas de la même conception.

Dans le code de rémiz, on dit

Pour chaque valeur de x incrémentée de 1, tant que x est strictement inférieure à 100, on teste si val est égal à tab[x]. Si ce test est valide on saute à un endroit appelé FinRecherche (avec goto) ainsi la boucle est stopée ou on sort de la boucle for (avec break.

Dans mon code, on dit

Pour chaque valeur de x incrémentée de 1, tant que la valeur de x est strictement inférieure à 100 ET que val est différent de tab[x], on continue la boucle. Si l'une des deux conditions n'est pas respectée, la boucle est stoppée.

Il n'y a plus d'instruction pour dire que faire lorsque une condition est vérifiée comme c'est le cas dans le code de Rémiz.


Sinon personnellement, on m'a fortement déconseillé le goto car ça va devenir illisible au fur et à mesure du développement des logiciels. Le break et continue est à utiliser avec modération.

Néamoins J'utilise break uniquement pour le switch.

Franchement, je vais répéter ce qui a été dit dans ce topic, le goto casse la logique d'un programme, car quand on lit un programme et dés qu'on aperçoit un goto, il faudra chercher l'endroit pour continuer la logique de lecture ensuite revenir au point de goto pour voir si ça continue juste après la ligne ou il y a goto

C'est casse tête chinois pour la lecture.

Tandis que sans goto, on s'y prend le plaisir de lire du début jusqu'a la fin du programme et comprendre le programme

[Newgaia]

slt,
En ce qui concerne le goto, une ancienne légende dit qu'il est trop attaché à l'assembleur. Il fait peur à certains, c'est un peu une chasse au sorcière. Qu'importe, il faut savoir ce que tu veux, si ton programme est à usage perso, non probleme, sinon commente. Mais il ne faut pas barnir certaines formes du langage sous prétexte que dans les temps anciens, bien des origines de bug venait d'un goto mal controlé...

M'enfin n'oublies pas Java bien et C tant mieux


8)

[vic]

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 ?

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

Permier cas, traitement d'erreur. 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
15
16
17
18
19
20
21
22
23
24
int fonction() {
    /* traitement 1 ... */
    if( <erreur> ) {
        /* nettoyage  */
        return <code_erreur_1>;
    }
 
    /* traitement 2 ... */
    if( <erreur 2> ) {
        /* nettoyage  */
        return <code_erreur_2>;
    }
 
    /* traitement 3... */
    if( <erreur 3> ) {
        /* nettoyage  */
        return <code_erreur_3>;
    }
 
    // etc ...
 
    /* nettoyage  */
    return <ok>;
}

Evidement on a un gros problème de code redondant, difficile à changer. On peut avantageusement le remplacer par la chose suivante :

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
17
18
19
20
21
22
23
24
25
26
int fonction() {
    int ret = <ok>;
 
    /* traitement 1 ... */
    if( <erreur> ) {
        ret = <code_erreur_1>;
        goto fin;
    }
 
    /* traitement 2 ... */
    if( <erreur 2> ) {
        ret = <code_erreur_2>;
        goto fin;
    }
 
    /* traitement 3... */
    if( <erreur 3> ) {
        ret = <code_erreur_3>;
        goto fin;
    }
 
    // etc ...
 
    fin:
    /* nettoyage  */
    return ret;

Certains pourront dire qu'on peut utiliser une fonction dans ce cas, mais celà peut ajouter une complexité inutile s'il y a beaucoup de termes à traiter et de plus on doit également modifier les paramètres de la fonction si on doit modifier le code de nettoyage.


Deuxième cas, pouvoir sortir rapidement d'une construction très complexe et remonter une erreur. 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
15
16
17
18
19
20
21
22
23
24
25
26
while( <...> ) {
    /* traitements ...*/
    if( <...> ) {
        /* traitements ... */
    } else {
        /* traitements ...*/
        for( <...> ) {
            if( <...> ) {
                /* traitements ...*/
                if( <erreur> )
                    goto fin_while;
                /* traitements ...*/
            } else if( <...> ) {
                /* traitements ...*/
            } else {
                /* traitements ...*/
                if( <erreur> )
                    goto fin_while;
                /* traitements ...*/
            }
        }
        /* traitements ...*/
    }
    /* traitements ...*/
    fin_while:
}

Imaginez le code précédent avec 10 ou 15 niveaux d'imbrications et autant de remontées d'erreur possibles (on trouve ce genre de code dans le noyau linux en particulier). Je défie quiconque d'arriver à écrire quelquechose de lisible en utilisant uniquement des flags et des tests Le goto permet d'obtenir un code plus simple et plus lisible et semble donc ici le meilleur choix.

Je justifie ma position en disant la chose suivante : si une technique de programmation rend à la fois le code plus clair et plus efficace, alors c'est elle qu'on doit choisir. Baser sa décision sur un dogmatisme quasi pavlovien ("le goto c'est mal") ne mène nulle part.

[amaury pouly]

Je voudrais juste dire mon avis personnel:
certes le goto en général c'est mal et moi même je l'utilise très rarement et je le déconseille
MAIS
il est des cas très particulier où il me semble qu'il peut être utilisé sans risque et surtout il est des cas où ne pas l'utiliser peut rendre le code encore pire . Je ne ferais que citer le cas des imbrications multiples à condition que les boucles ne soient pas trop grandes(dans ce cas mieux vaut une fonction et un test) .
Je citerais aussi un cas très particulier qui m'est déjà arrivé:

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
17
18
 
switch(...)
case
....
case
....
case
...
case <machin>
  if <truc>
     goto Lcase_truc
  else
    ....
case
...
case ..
Lcase_truc:
....

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

[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