Quelqu'un utilise-t-il encore [goto] en C # et si oui, pourquoi? [fermé]

Je me demandais si quelqu'un utilise toujours la syntaxe du mot-clé "goto" en C # et quelles sont les raisons possibles de le faire.

J'ai tendance à considérer toutes les déclarations qui poussent le lecteur à parcourir le code comme une mauvaise pratique, mais je me demande s'il existe des scénarios crédibles pour utiliser une telle syntaxe.

Aller à la définition des mots-clés

Il existe quelques (rares) cas où goto peut améliorer la lisibilité. En fait, la documentation que vous avez liée à deux exemples:

Une utilisation courante de goto consiste à transférer le contrôle vers une étiquette de cas de commutation spécifique ou l'étiquette par défaut dans une instruction de commutation.

L'instruction goto est également utile pour sortir des boucles profondément imbriquées.

Voici un exemple pour ce dernier:

for (...) {
    for (...) {
        ...
        if (something)
            goto end_of_loop;
    }
}

end_of_loop:

Bien sûr, il existe également d'autres moyens de contourner ce problème, comme la refactorisation du code dans une fonction, l'utilisation d'un bloc factice autour de lui, etc. (voir cette question pour plus de détails). En remarque, les concepteurs du langage Java ont décidé d'interdire complètement goto et d'introduire une instruction break étiquetée à la place.

Je me souviens de cette partie

switch (a)     
{ 
    case 3: 
        b = 7;
        // We want to drop through into case 4, but C# doesn't let us
    case 4: 
        c = 3;
        break; 
    default: 
        b = 2;
        c = 4;
        break; 
}

À quelque chose comme ça

switch (a)     
{
    case 3: 
        b = 7;
        goto case 4;    
    case 4: 
        c = 3;
        break;     
    default: 
        b = 2;
        c = 4;
        break;
}

Référez ceci

Je l'utilise abondamment dans Eduasync pour montrer le type de code que le compilateur génère pour vous lorsque vous utilisez des méthodes async en C # 5. Vous verriez la même chose dans les blocs d'itérateur.

En code "normal" cependant, je ne me souviens plus de la dernière fois que je l'ai utilisé ...

goto est idéal pour sortir de nombreuses boucles où break ne fonctionnerait pas bien (disons en cas d'erreur), et comme Kragen l'a dit, goto est utilisé par le compilateur pour générer des instructions switch et d'autres choses.

Je ne me souviens pas avoir jamais utilisé goto. Mais peut-être que cela améliore l'intention d'une boucle éternelle que vous ne voulez vraiment jamais quitter (non break, mais vous pouvez toujours returnou throw):

forever: {
  // ...
  goto forever;
}

Là encore, un simple while (true)devrait suffire ...

Aussi, vous pouvez utiliser dans une situation où vous voulez que la première itération d'une boucle commence au milieu de la boucle: regardez ici pour un exemple.

Le compilateur utilise des gotoinstructions dans divers morceaux de code généré, par exemple dans les types de blocs d'itérateur générés (générés lors de l'utilisation du yield returnmot-clé - je suis presque sûr que les types de sérialisation XML générés contiennent également quelques gotoinstructions quelque part.

Voir Détails de l'implémentation du bloc Iterator: machines à états générées automatiquement pour plus de détails sur pourquoi / comment le compilateur C # gère cela.

À part le code généré, il n'y a pas de bonne raison d'utiliser une gotoinstruction dans du code normal - cela rend le code plus difficile à comprendre et par conséquent plus sujet aux erreurs. D'autre part en utilisantgoto instructions dans du code généré comme celui-ci peut simplifier le processus de génération et est normalement bien car personne ne va lire (ou modifier) ​​le code généré et il n'y a aucune chance que des erreurs soient commises car une machine est en train d'écrire.

Voir la déclaration Go-to considérée comme nuisible pour un argument contre gotoainsi qu'un morceau classique de l'histoire de la programmation.

Le processeur implémente au moins une instruction de saut et je suis sûr que beaucoup d'instructions utilisent celles-ci dans leur implémentation ou leur interprétation.

L'une des bonnes choses à propos de l'utilisation d'un langage de 3e ou 4e génération est que ces détails physiques nous sont abstraits. Alors que nous devrions être conscients de la loi de l'abstraction qui fuit, je pense que nous devrions également utiliser nos outils comme ils le sont ( désolé ). Si j'écrivais du code et que cela gotome semblait une bonne idée, il serait temps de refactoriser. Le but d'un langage structuré est d'éviter ces "sauts" et de créer un flux logique dans notre ingénierie.

Je devrais éviter l'utilisation de, breakmais je ne peux pas ignorer les avantages en termes de performances. Cependant, si j'ai des boucles imbriquées qui en ont besoin mutuellement, breakil est temps de refactoriser.

Si quelqu'un peut proposer une utilisation de gotocela semble mieux que la refactorisation, je retirerai volontiers ma réponse.

J'espère que je ne suis pas coupable de m'être précipité dans le "local à vélos " ici. Comme le dit Kragen, ce qui est assez bien pour Dijkstra me suffit.

Goto n'est jamais mieux. Et continuez, break (sauf dans switch / case), (multiple) return, et throw devrait également être maintenu au minimum. Vous ne voulez jamais vous échapper du milieu des boucles de nidification. Vous voulez toujours que les instructions de contrôle de boucle aient tout le contrôle de boucle. La mise en retrait contient des informations, et toutes ces instructions jettent ces informations. Vous pouvez aussi bien supprimer toutes les mises en retrait.