Rompre une boucle "for" en utilisant "break" est-il dangereux?
Il y a quelques jours, j'ai commencé un projet open source rapide et, lorsque certains amis ont regardé le code sur svn, l'un d'eux m'a dit que l'utilisation de l'instruction break dans une boucle for est considérée comme nuisible et ne devrait pas pas fini.
Il a ajouté, cependant, que je trouverais plusieurs cas d'instructions break dans des boucles for sur le code source du noyau Linux, mais c'était simplement parce que seuls Linus Torvalds et Chuck Norris étaient autorisés à l'utiliser et personne d'autre.
Qu'est-ce que tu penses? Je ne vois aucun problème à utiliser break dans une boucle for. À mon avis, émuler le comportement de break en utilisant des variables booléennes ou quelque chose de similaire ajoute beaucoup de frais généraux inutiles et rend le code moins simple.
De plus, il n'y a pas de place pour la comparaison avec goto, car break ne peut pas modifier arbitrairement le flux du programme d'un point à l'autre. goto le fait.
Je ne vois aucun problème à utiliser des pauses. Dans certains cas, vous souhaiterez arrêter le traitement d'une boucle et utiliser un break; a beaucoup plus de sens (et le rend plus lisible!) que de définir votre compteur de boucles à une valeur qui ferait arrêter votre boucle à la prochaine itération.
Obligatoire:
Le fait est que vous ne devez pas l'éviter uniquement en raison de mauvaises pratiques (ou de vélociraptors), mais envisagez au cas par cas.
Tout est question de clarté. Comme vous l'avez dit, vous n'avez jamais à l'utiliser, mais dans certains cas, cela favorise la lisibilité. C'est utile lorsque la boucle se termine généralement normalement, mais dans de rares cas, vous devez renflouer. Les boucles qui se cassent généralement (ou toujours) sont plus une odeur de code (mais pourraient toujours être appropriées).
Non seulement il n'y a aucun problème à utiliser break, mais je dirais que quiconque dit qu'il est "considéré comme dangereux" est carrément faux.
break est une fonction de langage utilisée pour interrompre une boucle - vous pouvez utiliser goto, mais vous encourez la colère (appropriée) de la bande dessinée XKCD ci-dessous. Vous pouvez utiliser un indicateur dans la condition, mais cela nuit à la lisibilité. break n'est pas seulement le moyen le plus simple, mais aussi le plus clair à plusieurs reprises pour sortir d'une boucle. Utilisez-le comme il devait être utilisé.
Edit: Pour obtenir une image plus grande ici: Lorsque vous écrivez du code, le principe directeur "devrais-je utiliser la fonction de langage X ou Y" devrait être ", ce qui entraînera le code le plus élégant "? L'élégance, dans le code, est à peu près un art, mais je le définirais comme un équilibre fin entre la lisibilité et l'efficacité algorithmique (lire: pas les micro-optimisations). La lisibilité va être déterminée par la longueur, la complexité du code, etc. Un boost :: bind sur une ligne peut très bien être plus difficile à lire et à comprendre qu'une boucle de 3 lignes.
Si une fonction de langage peut vous aider à écrire du code plus facile à comprendre lors de l'exécution du travail, utilisez-le. Cela s'applique aux break, goto, aux exceptions C++, etc. Ne suivez pas aveuglément un "X est (mal | considéré comme nuisible)" - appliquez le bon sens et la logique à chaque fois.
Non seulement il n'y a pas de problème avec break, c'est aussi OK pour utiliser goto lorsque break est insuffisant. N'ayez pas peur non plus des retours multiples.
Tout ce qui précède ne s'applique que si cela rend le code plus facile à comprendre *.
* Et si votre PHB le permet ...
Je pense que ton compagnon est fou. break est parfaitement acceptable, parfaitement lisible et parfaitement maintenable. Période.
Il existe un paradigme selon lequel toute boucle ne devrait avoir qu'un seul point de sortie (la même chose qu'une fonction ne devrait avoir qu'un seul retour). Cela a à voir avec la lisibilité. Trop de points de sortie peuvent rendre le code très difficile à comprendre. De plus, c'est important si vous voulez faire une vérification de code (c'est-à-dire une preuve mathématique si votre code est correct).
Cependant, les directives sont souvent là pour vous aider, mais elles ne sont pas strictes. Il y a peut-être des situations où une pause vaut mieux que de ne pas l'utiliser. Par conséquent, il faut être pragmatique à ce sujet, mais comprendre la raison de ces principes afin de créer un bon code.
Je pense que cela dépend du contexte. Bien qu'il puisse s'agir d'un "mauvais" style de codage dans certaines situations, je ne peux pas penser à un cas où ce serait nuisible.
En fait, dans certains cas, je le recommanderais. Par exemple, si vous utilisiez une recherche linéaire, dans tous les cas (sauf le pire des cas), un Je pense que sortir de la boucle lorsque vous avez trouvé votre aiguille serait parfaitement acceptable, et ce serait plus lisible que de jouer avec la variable de boucle (qui pourrait ne pas être uniquement utilisée pour la boucle, en fonction de votre programme) ou envelopper le corps de la boucle dans un bloc break améliorerait votre vitesse.if. (Et l'autre option, un if qui contient continue, combine le pire des deux mondes: encapsuler la logique de boucle dans un bloc if et le mauvais style de codage contre des gens comme vos amis qui n'aiment pas break.)
L'incrémentation de votre compteur de boucles au lieu d'utiliser break signifie également que vous avez terminé d'exécuter l'itération actuelle de la boucle, ce qui peut être souhaitable ou non.
Bien sûr, vous pouvez envelopper le reste dans une clause if, puis recommencer lorsque vous réalisez que vous devez vérifier s'il faut ou non arrêter la boucle plusieurs fois, et vous le ferez rapidement comprendre pourquoi les gens utilisent break;
Je suggère cet algorithme si vous envisagez d'utiliser une technique donnée.
- Si elle est considérée bonne pratique:
- utilise le.
- Si c'est pas considéré comme une bonne pratique:
- ne l'utilisez que si vous la jugez la meilleure solution à long terme.
- Si elle est considérée mal:
- ne l'utilisez que si vous la jugez la meilleure solution à long terme et que vous êtes extrêmement confiant dans votre jugement. Méfiez-vous: les choses considérées comme mauvaises ont tendance à être trompeusement attrayantes.
Je classerais break; comme "pas une bonne pratique". Utilisez-le lorsqu'il rend le code plus lisible, réduit les risques de bogues, ne complique pas le débogage, etc.