Est-ce une mauvaise pratique d'utiliser le break in a for loop? [fermé]

Est-ce une mauvaise pratique d'utiliser une breakinstruction dans une forboucle ?

Dites, je recherche une valeur dans un tableau. Comparez à l'intérieur d'une boucle for et lorsque la valeur est trouvée, break;pour quitter la boucle for.

Est-ce une mauvaise pratique? J'ai vu l'alternative utilisée: définir une variable vFoundet la définir sur true lorsque la valeur est trouvée et vérifier vFoundla forcondition de l' instruction. Mais est-il nécessaire de créer une nouvelle variable uniquement dans ce but?

Je demande dans le contexte d'une boucle for normale en C ou C ++.

PS: Les directives de codage MISRA déconseillent d'utiliser break.

Beaucoup de réponses ici, mais je n'ai pas encore vu cela mentionné:

La plupart des «dangers» associés à l'utilisation breakou continuedans une boucle for sont annulés si vous écrivez des boucles ordonnées et facilement lisibles. Si le corps de votre boucle s'étend sur plusieurs longueurs d'écran et a plusieurs sous-blocs imbriqués, oui, vous pourriez facilement oublier que du code ne sera pas exécuté après la pause. Si, cependant, la boucle est courte et précise, le but de l'instruction break doit être évident.

Si une boucle devient trop grande, utilisez plutôt un ou plusieurs appels de fonction bien nommés dans la boucle. La seule vraie raison d'éviter de le faire est le traitement des goulots d'étranglement.

Non, la pause est la bonne solution.

L'ajout d'une variable booléenne rend le code plus difficile à lire et ajoute une source potentielle d'erreurs.

Vous pouvez trouver toutes sortes de codes professionnels avec des instructions «break». Il est parfaitement logique de l'utiliser chaque fois que cela est nécessaire. Dans votre cas, cette option est meilleure que de créer une variable distincte dans le seul but de sortir de la boucle.

Utiliser breakaussi bien que continuedans une forboucle est parfaitement bien.

Il simplifie le code et améliore sa lisibilité.

Loin d'être une mauvaise pratique, Python (et d'autres langages?) A étendu la structure de la forboucle de sorte qu'une partie de celle-ci ne sera exécutée que si la boucle ne le fait pasbreak .

for n in range(5):
    for m in range(3):
        if m >= n:
            print('stop!')
            break
        print(m, end=' ')
    else:
        print('finished.')

Production:

stop!
0 stop!
0 1 stop!
0 1 2 finished.
0 1 2 finished.

Code équivalent sans breaket que pratique else:

for n in range(5):
    aborted = False
    for m in range(3):
        if not aborted:
            if m >= n:
                print('stop!')
                aborted = True
            else:            
                print(m, end=' ')
    if not aborted:
        print('finished.')

Il n'y a rien de mal en soi à utiliser une instruction break, mais les boucles imbriquées peuvent prêter à confusion. Pour améliorer la lisibilité, de nombreux langages ( du moins Java le fait ) prennent en charge le passage aux étiquettes, ce qui améliorera considérablement la lisibilité.

int[] iArray = new int[]{0,1,2,3,4,5,6,7,8,9};
int[] jArray = new int[]{0,1,2,3,4,5,6,7,8,9};

// label for i loop
iLoop: for (int i = 0; i < iArray.length; i++) {

    // label for j loop
    jLoop: for (int j = 0; j < jArray.length; j++) {

        if(iArray[i] < jArray[j]){
            // break i and j loops
            break iLoop;
        } else if (iArray[i] > jArray[j]){  
            // breaks only j loop
            break jLoop;
        } else {
            // unclear which loop is ending
            // (breaks only the j loop)
            break;
        }
    }
}

Je dirai que les instructions break (et return) augmentent souvent la complexité cyclomatique, ce qui rend plus difficile la preuve que le code fait la bonne chose dans tous les cas.

Si vous envisagez d'utiliser une pause lors de l'itération sur une séquence pour un élément particulier, vous voudrez peut-être reconsidérer la structure de données utilisée pour contenir vos données. L'utilisation de quelque chose comme un ensemble ou une carte peut fournir de meilleurs résultats.

break est une instruction tout à fait acceptable à utiliser (ainsi est continue , btw). Tout est question de lisibilité du code - tant que vous n'avez pas de boucles trop compliquées, c'est bien.

Ce n'est pas comme s'ils étaient de la même ligue que goto . :)

Règle générale: si suivre une règle vous oblige à faire quelque chose de plus maladroit et difficile à lire, alors enfreindre la règle, alors enfreignez la règle.

Dans le cas d'une boucle jusqu'à ce que vous trouviez quelque chose, vous rencontrez le problème de distinguer trouvé par rapport à introuvable lorsque vous sortez. C'est:

for (int x=0;x<fooCount;++x)
{
  Foo foo=getFooSomehow(x);
  if (foo.bar==42)
    break;
}
// So when we get here, did we find one, or did we fall out the bottom?

Alors d'accord, vous pouvez définir un indicateur ou initialiser une valeur "trouvée" à null. Mais

C'est pourquoi en général je préfère pousser mes recherches dans des fonctions:

Foo findFoo(int wantBar)
{
  for (int x=0;x<fooCount;++x)
  {
    Foo foo=getFooSomehow(x);
    if (foo.bar==wantBar)
      return foo;
  }
  // Not found
  return null;
}

Cela permet également de désencombrer le code. Dans la ligne principale, "find" devient une seule instruction, et lorsque les conditions sont complexes, elles ne sont écrites qu'une seule fois.

Cela dépend de la langue. Bien que vous puissiez éventuellement vérifier une variable booléenne ici:

for (int i = 0; i < 100 && stayInLoop; i++) { ... }

il n'est pas possible de le faire lors d'une itération sur un tableau:

for element in bigList: ...

Quoi qu'il en soit, breakcela rendrait les deux codes plus lisibles.

Dans votre exemple, vous ne connaissez pas le nombre d'itérations pour la boucle for . Pourquoi ne pas utiliser en place la boucle, ce qui permet le nombre d'itérations à durée indéterminée au début?

Il est donc pas nécessaire d'utiliser pause statemement en général, la boucle peut être mieux comme indiqué en boucle.

Je suis d'accord avec les autres qui recommandent d'utiliser break. La question évidente qui en découle est de savoir pourquoi quelqu'un recommanderait le contraire? Eh bien ... lorsque vous utilisez break, vous ignorez le reste du code dans le bloc et les itérations restantes. Parfois, cela provoque des bogues, par exemple:

• une ressource acquise en haut du bloc peut être libérée en bas (cela est vrai même pour les blocs à l'intérieur des forboucles), mais cette étape de libération peut être sautée accidentellement lorsqu'une sortie "prématurée" est provoquée par une breakinstruction (en "moderne" C ++, "RAII" est utilisé pour gérer cela de manière fiable et sans risque d'exception: en gros, les destructeurs d'objets libèrent des ressources de manière fiable, quelle que soit la façon dont une portée est sortie)

• quelqu'un peut changer le test conditionnel dans l' forinstruction sans remarquer qu'il existe d'autres conditions de sortie délocalisées

• La réponse de ndim observe que certaines personnes peuvent éviter breaks pour maintenir un temps d'exécution de boucle relativement cohérent, mais vous compariez breakà l'utilisation d'une variable de contrôle booléenne de sortie précoce où cela ne tient pas

De temps en temps, les gens qui observent de tels bogues se rendent compte qu'ils peuvent être évités / atténués par cette règle "sans interruption" ... en effet, il existe toute une stratégie connexe pour une programmation "plus sûre" appelée "programmation structurée", où chaque fonction est censée avoir un point d'entrée et de sortie unique aussi (c'est-à-dire pas de goto, pas de retour anticipé). Il peut éliminer certains bogues, mais il en introduit sans doute d'autres. Pourquoi font-ils cela?

• ils ont un cadre de développement qui encourage un style particulier de programmation / code, et ils ont des preuves statistiques que cela produit un avantage net dans ce cadre limité, ou
• ils ont été influencés par les directives de programmation ou par l'expérience dans un tel cadre, ou
• ce ne sont que des idiots dictatoriaux, ou
• n'importe laquelle de l'inertie historique ci-dessus + (pertinente en ce que les justifications sont plus applicables au C qu'au C ++ moderne).

Son utilisation est parfaitement valable break- comme d'autres l'ont souligné, ce n'est nulle part dans la même ligue que goto.

Bien que vous souhaitiez peut-être utiliser la vFoundvariable lorsque vous souhaitez vérifier en dehors de la boucle si la valeur a été trouvée dans le tableau. Du point de vue de la maintenabilité également, il pourrait être utile d'avoir un indicateur commun signalant les critères de sortie.

J'ai fait quelques analyses sur la base de code sur laquelle je travaille actuellement (40 000 lignes de JavaScript).

Je n'ai trouvé que 22 breakdéclarations, parmi lesquelles:

• 19 ont été utilisées à l'intérieur des switchinstructions (nous n'avons que 3 instructions switch au total!).
• 2 ont été utilisés à l'intérieur de forboucles - un code que j'ai immédiatement classé comme devant être refactoré en fonctions distinctes et remplacé par returninstruction.
• Quant à la dernière boucle breakintérieure while... j'ai couru git blamevoir qui a écrit cette merde!

Donc selon mes statistiques: si breakest utilisé en dehors de switch, c'est une odeur de code.

J'ai également recherché des continuedéclarations. Aucun trouvé.

Je ne vois aucune raison pour laquelle ce serait une mauvaise pratique à condition que vous souhaitiez terminer le traitement STOP à ce stade.

Dans le monde embarqué, il existe de nombreux codes utilisant la construction suivante:

    while(1)
    { 
         if (RCIF)
           gx();
         if (command_received == command_we_are_waiting_on)
           break;
         else if ((num_attempts > MAX_ATTEMPTS) || (TickGet() - BaseTick > MAX_TIMEOUT))
           return ERROR;
         num_attempts++;
    }
    if (call_some_bool_returning_function())
      return TRUE;
    else
      return FALSE;

C'est un exemple très générique, beaucoup de choses se passent derrière le rideau, des interruptions en particulier. N'utilisez pas cela comme code standard, j'essaie juste d'illustrer un exemple.

Mon opinion personnelle est qu'il n'y a rien de mal à écrire une boucle de cette manière tant que des précautions appropriées sont prises pour éviter de rester indéfiniment dans la boucle.

Dépend de votre cas d'utilisation. Il existe des applications où le temps d'exécution d'une boucle for doit être constant (par exemple pour satisfaire certaines contraintes de temps, ou pour cacher vos données internes aux attaques basées sur le temps).

Dans ces cas, il sera même judicieux de définir un indicateur et de ne vérifier la valeur de l'indicateur qu'APRÈS que toutes les foritérations de boucle se sont réellement déroulées. Bien sûr, toutes les itérations de la boucle for doivent exécuter du code qui prend toujours à peu près le même temps.

Si vous ne vous souciez pas du temps d'exécution ... utilisez break;et continue;pour rendre le code plus facile à lire.

Sur les règles MISRA 98, qui sont utilisées sur mon entreprise en C dev, l'instruction break ne doit pas être utilisée ...

Edit: la pause est autorisée dans MISRA '04

Bien sûr, break;c'est la solution pour arrêter la boucle for ou foreach. Je l'ai utilisé en php dans foreach et for loop et j'ai trouvé que cela fonctionnait.

Je ne suis pas d'accord!

Pourquoi ignoreriez-vous la fonctionnalité intégrée d'une boucle for pour créer la vôtre? Vous n'avez pas besoin de réinventer la roue.

Je pense qu'il est plus logique d'avoir vos chèques en haut de votre boucle for comme ça

for(int i = 0; i < myCollection.Length && myCollection[i].SomeValue != "Break Condition"; i++)
{
//loop body
}

ou si vous devez d'abord traiter la ligne

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
//loop body
}

De cette façon, vous pouvez écrire une fonction pour tout exécuter et créer un code beaucoup plus propre.

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

Ou si votre condition est compliquée, vous pouvez également déplacer ce code!

for(int i = 0; i < myCollection.Length && BreakFunctionCheck(i, myCollection); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

«Code professionnel» qui est criblé de pauses ne me semble pas vraiment un code professionnel. Cela ressemble à du codage paresseux;)