Cela justifie-t-il les déclarations goto?

Je suis tombé sur cette question il y a une seconde, et j'en retire une partie du matériel: y a- t-il un nom pour la construction «break n»?

Cela semble être un moyen inutilement complexe pour les gens d'avoir à demander au programme de sortir d'une boucle for double-nested:

for (i = 0; i < 10; i++) {
    bool broken = false;
    for (j = 10; j > 0; j--) {
        if (j == i) {
            broken = true;
            break;
        }
    }
    if (broken)
        break;
}

Je sais que les manuels aiment dire que les déclarations goto sont le diable, et je ne les aime pas du tout moi-même, mais cela justifie-t-il une exception à la règle?

Je cherche des réponses qui traitent des boucles n-imbriquées.

REMARQUE: Que vous répondiez oui, non ou quelque part entre les deux, les réponses totalement étroites ne sont pas les bienvenues. Surtout si la réponse est non, fournissez une bonne raison légitime (ce qui n'est pas trop loin de la réglementation Stack Exchange de toute façon).

Le besoin apparent d'une instruction go-to vient de votre choix d'expressions conditionnelles médiocres pour les boucles .

Vous déclarez que vous vouliez que la boucle externe continue aussi longtemps i < 10et la boucle la plus interne se poursuive aussi longtemps j > 0.

Mais en réalité, ce n'est pas ce que vous vouliez , vous n'avez tout simplement pas dit aux boucles l'état réel que vous vouliez qu'elles évaluent, puis vous voulez le résoudre en utilisant break ou goto.

Si vous dites aux boucles vos véritables intentions pour commencer , alors pas besoin de pauses ou de goto.

bool alsoThis = true;
for (i = 0; i < 10 && alsoThis; i++)
{    
    for (j = 10; j > 0 && alsoThis; j--)
    {
        if (j == i)
        {
            alsoThis = false;
        }
    }
}

Dans ce cas, vous pouvez refactoriser le code dans une routine distincte, puis uniquement à returnpartir de la boucle interne. Cela annulerait la nécessité de sortir de la boucle extérieure:

bool isBroken() {
    for (i = 0; i < 10; i++)
        for (j = 10; j > 0; j--)
            if (j == i) return true;

    return false;
}

Non, je ne pense pas qu'un gotosoit nécessaire. Si vous l'écrivez comme ceci:

bool broken = false;
saved_i = 0;
for (i = 0; i < 10 && !broken; i++)
{
    broken = false;
    for (j = 10; j > 0 && !broken; j--)
    {
        if (j == i)
        {
            broken = true;
            saved_i = i;
        }
    }
}

Avoir &&!brokensur les deux boucles vous permet de sortir des deux boucles quand i==j.

Pour moi, cette approche est préférable. Les conditions de boucle sont extrêmement claires: i<10 && !broken.

Une version de travail peut être consultée ici: http://rextester.com/KFMH48414

Code:

public static void main(String args[])
{
    int i=0;
    int j=0;
    boolean broken = false;
    for (i = 0; i < 10 && !broken; i++)
    {
        broken = false;
        for (j = 10; j > 0 && !broken; j--)
        {
            if (j == i)
            {
                broken = true;
                System.out.println("loop breaks when i==j=="+i);
            }
        }
    }
    System.out.println(i);
    System.out.println(j);
}

Production:

la boucle se brise lorsque i == j == 1
2
0

La réponse courte est "ça dépend". Je préconise de choisir en ce qui concerne la lisibilité et la compréhensibilité de votre code. Le chemin d'accès peut être plus lisible que de modifier la condition, ou vice versa. Vous pouvez également prendre en compte le principe de la moindre surprise, les directives utilisées dans la boutique / le projet et la cohérence de la base de code. Par exemple, goto pour quitter le commutateur ou pour la gestion des erreurs est une pratique courante dans la base de code du noyau Linux. Notez également que certains programmeurs peuvent avoir des problèmes de lecture de votre code (soit soulevé avec le mantra "goto is evil", ou tout simplement pas appris parce que leur professeur le pense) et certains d'entre eux pourraient même "vous juger".

D'une manière générale, un aller plus loin dans la même fonction est souvent acceptable, surtout si le saut n'est pas trop long. Votre cas d'utilisation de quitter une boucle imbriquée est l'un des exemples connus de goto "pas si mal".

Dans votre cas, goto est une amélioration suffisante pour paraître tentante, mais ce n'est pas tant une amélioration qu'il vaut la peine d'enfreindre la règle contre leur utilisation dans votre base de code.

Pensez à votre futur critique: il devra penser: "Est-ce que cette personne est un mauvais codeur ou est-ce en fait un cas où le goto en valait la peine? Permettez-moi de prendre 5 minutes pour décider par moi-même ou faire une recherche sur le l'Internet." Pourquoi diable feriez-vous cela à votre futur codeur alors que vous ne pouvez pas utiliser goto entièrement?

En général, cette mentalité s'applique à tout "mauvais" code et le définit même: si cela fonctionne maintenant, et est bon dans ce cas, mais crée des efforts pour vérifier qu'il est correct, ce qui à cette époque un goto fera toujours, alors ne le faites pas fais le.

Cela étant dit, oui, vous avez produit l'un des cas légèrement plus épineux. Tu peux:

• utiliser des structures de contrôle plus complexes, comme un drapeau booléen, pour sortir des deux boucles
• mettre votre boucle intérieure dans sa propre routine (idéal idéal)
• mettre les deux boucles dans une routine et revenir au lieu de casser

Il est très difficile pour moi de créer un cas où une double boucle n'est pas si cohérente qu'elle ne devrait de toute façon pas être sa propre routine.

Soit dit en passant, la meilleure discussion à ce sujet que j'ai vue est le code complet de Steve McConnell . Si vous aimez penser à ces problèmes de manière critique, je vous recommande fortement de lire, même de couverture en couverture malgré son immensité.

TLD; DR: non en particulier, oui en général

Pour l'exemple spécifique que vous avez utilisé, je dirais non pour les mêmes raisons que beaucoup d'autres ont signalées. Vous pouvez facilement refactoriser le code sous une forme équivalente qui élimine le besoin de goto.

En général, la proscription contre gotoest une généralité basée sur la nature comprise gotoet le coût de son utilisation. Une partie du génie logiciel prend des décisions de mise en œuvre. La justification de ces décisions se produit en pesant le coût par rapport aux avantages et chaque fois que les avantages l'emportent sur le coût, la mise en œuvre est justifiée. La controverse découle de différentes évaluations, à la fois en termes de coûts et d'avantages.

Le fait est qu'il y aura toujours des exceptions où a gotoest justifié, mais seulement pour certains en raison de valorisations différentes. Le dommage est que de nombreux ingénieurs excluent simplement les techniques dans une ignorance délibérée car ils les lisent sur Internet plutôt que de prendre le temps de comprendre pourquoi.

Je ne pense pas que ce cas justifie une exception, car cela peut s'écrire:

def outerLoop(){
    for (i = 0; i < 10; i++) {
        if( broken?(i) )
          return; // broken
    }
}

def broken?(i){
   for (j = 10; j > 0; j--) {
        if (j == i) {
            return true; // broken
        }
   }
   return false; // not broken
}