Est-ce une mauvaise pratique à utiliser break dans une boucle for?

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

La plupart des "dangers" liés à l'utilisation break ou continue dans une boucle for sont annulés si vous écrivez bien rangé, facilement lisible par les boucles. Si le corps de la boucle s'étend sur plusieurs écran longueurs et a de multiples imbriquée des sous-blocs, oui, vous pouvez facilement oublier que le code ne sera pas exécuté après la pause. Si, toutefois, la boucle est court et au point, le but de l'instruction break devrait être évident.

Si une boucle est devenu trop grand, utiliser un ou plusieurs bien-nommé appels de fonction à l'intérieur de la boucle de la place. La seule vraie raison pour éviter de faire est pour le traitement des goulets d'étranglement.

OriginalL'auteur e.James

Vous pouvez trouver toutes sortes de professionnels de code avec "casser" des états. C'est parfaitement logique d'utiliser cette chaque fois que nécessaire. Dans votre cas, cette option est préférable à la création d'une variable distincte juste dans le but de sortir de la boucle.

OriginalL'auteur Amit S

Loin d'être une mauvaise pratique, Python (et d'autres langues?) étendue de la for de la boucle structure d'une partie de celui-ci va seulement être exécuté que si la boucle n'est pas break.

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

De sortie:

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

Code équivalent sans break et à portée de main 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.')

OriginalL'auteur Nick T

Il n'y a rien d'intrinsèquement mauvais avec l'aide d'une instruction de saut, mais les boucles imbriquées peut prêter à confusion. Afin d'améliorer la lisibilité de nombreuses langues (au moins, Java ne) soutien à la rupture à des étiquettes qui va grandement améliorer 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 la pause (et retour), les déclarations d'augmenter la la complexité cyclomatique ce qui le rend plus difficile à prouver code est en train de faire la bonne chose dans tous les cas.

Si vous envisagez de l'utiliser d'une pause lors de l'itération sur une séquence pour certains élément particulier, vous pourriez vouloir reconsidérer la structure de données utilisée pour stocker vos données. En utilisant quelque chose comme un Ensemble ou d'une Carte peut fournir de meilleurs résultats.

OriginalL'auteur cyber-monk

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

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

il n'est pas possible de le faire lorsque itering sur un tableau:

for element in bigList: ...

De toute façon, break serait de faire les deux codes plus lisible.

OriginalL'auteur eumiro

Je suis d'accord avec les autres qui vous recommandons d'utiliser break. L'évidence consécutifs question est de savoir pourquoi quelqu'un aurait-il recommander? Eh bien... quand vous utilisez pause, vous passez le reste du code dans le bloc, et les autres itérations. Cela entraîne parfois des bugs, par exemple:

• une ressource acquise au sommet du bloc peut être libéré sur le fond (ce qui est vrai même pour les blocs à l'intérieur de for boucles), mais que l'étape de libération peut être accidentellement sauté lors d'un "prématuré" de sortie est causée par un break déclaration (dans "modern" C++ "RAII" est utilisé pour gérer cela dans un fiable et d'exception-sûre: en fait, l'objet de destructeurs de libérer des ressources de manière fiable, peu importe la façon dont un champ d'application est quittée)

• quelqu'un peut modifier le test conditionnel dans le for déclaration, sans remarquer qu'il y a d'autres délocalisée conditions de sortie de

• ndim réponse observe que certaines personnes peuvent éviter breaks pour maintenir un niveau relativement cohérente de la boucle d'exécution, mais vous étiez en comparant break contre l'usage d'un booléen début de la sortie de variable de contrôle où il n'en est pas

Chaque maintenant et puis les gens l'observation de ces bugs se rendre compte qu'ils peuvent être évités/atténué par ce "sans casse" la règle... en effet, il y a toute une stratégie connexe pour la "sécurité" de programmation appelé "programmation structurée", où chaque fonction est censé avoir une seule entrée et à la sortie (c'est à dire pas de goto, pas de retour anticipé). Il peut éliminer les quelques bugs, mais sans doute introduit d'autres. Pourquoi font-ils cela?

• ils ont un cadre de développement qui encourage un style particulier de la programmation /code, et qu'ils ont des preuves statistiques qu'il produit un net avantage dans ce cadre limité, ou
• ils ont été influencés par les lignes directrices de la programmation ou de l'expérience dans un tel cadre, ou
• ils sont juste dictatorial idiots, ou
• ci-dessus + l'inertie de l'histoire (pertinent dans la mesure où les justifications sont plus applicables à C que le C++ moderne).

OriginalL'auteur Tony Delroy

Je ne vois pas pourquoi ce serait une mauvaise habitude que vous voulez ARRÊTER complètement le traitement à ce stade.

OriginalL'auteur Cornelius J. van Dyk

Dans le monde embarqué, il y a beaucoup de code qui utilise les éléments suivants construire:

    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 très générique exemple, beaucoup de choses qui se passe derrière le rideau, les interruptions en particulier. Ne pas l'utiliser comme code réutilisable, j'essaie juste d'illustrer un exemple.

Mon opinion personnelle est qu'il n'y a rien de mal avec l'écriture d'une boucle de cette manière, tant qu'il prenne les précautions prises pour empêcher restant dans la boucle indéfiniment.

OriginalL'auteur Nate

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

Edit : interruption est autorisée dans MISRA '04

OriginalL'auteur Benoît

Bien sûr, break; est la solution pour arrêter la boucle for ou une boucle foreach. Je l'ai utilisé en php foreach et pour la boucle et trouvé de travail.

OriginalL'auteur gautamlakum