'<' versus '! =' comme condition dans une boucle 'for'?

Supposons que vous ayez la forboucle suivante *:

for (int i = 0; i < 10; ++i) {
    // ...
}

qui pourrait aussi s'écrire:

for (int i = 0; i != 10; ++i) {
    // ...
}

Les résultats finaux sont les mêmes, donc y a-t-il des arguments réels pour utiliser l'un sur l'autre? Personnellement, j'utilise l'ancien au cas où, ipour une raison quelconque, se détraquerait et sauterait la valeur 10.

_{* Excusez l'utilisation des nombres magiques, mais ce n'est qu'un exemple.}

La raison de choisir l'un ou l'autre est en raison de l' intention et en conséquence, cela augmente la lisibilité .

Intention: la boucle doit s'exécuter aussi longtemps qu'elle iest inférieure à 10, pas aussi longtemps qu'elle in'est pas égale à 10. Même si cette dernière peut être la même dans ce cas particulier, ce n'est pas ce que vous voulez dire, donc elle ne devrait pas être écrit comme ça.

Lisibilité: en écrivant ce que vous voulez dire, c'est aussi plus facile à comprendre. Par exemple, si vous utilisez i != 10, quelqu'un qui lit le code peut se demander si à l'intérieur de la boucle il y a un moyen qui ipourrait devenir plus grand que 10 et que la boucle devrait continuer (btw: c'est un mauvais style de jouer avec l'itérateur ailleurs que dans la tête de la fordéclaration, mais cela ne signifie pas que les gens ne le font pas et, par conséquent, les responsables s'y attendent).

Le <modèle est généralement utilisable même si l'incrément n'est pas exactement 1.

Cela permet une seule façon commune de faire des boucles, quelle que soit la façon dont cela est réellement fait.

En C ++, la recommandation de Scott Myers dans C ++ plus efficace (élément 6) est toujours d'utiliser la seconde, sauf si vous avez une raison de ne pas le faire, car cela signifie que vous avez la même syntaxe pour les index d'itérateur et d'entier afin que vous puissiez échanger de manière transparente entre intet itérateur. sans aucun changement de syntaxe.

Dans d'autres langues, cela ne s'applique pas, donc je suppose que <c'est probablement préférable en raison de l'argument de Thorbjørn Ravn Andersen.

Soit dit en passant, l'autre jour , je discutais avec un autre développeur et il a dit la raison de préférer <plus !=est parce que ipourrait incrémenter accidentellement par plus d'un, et qui pourrait causer la condition de rupture ne soit pas présente; c'est IMO une charge de non-sens.

L'utilisation de (i <10) est à mon avis une pratique plus sûre. Il attrape le nombre maximum de cas de sortie potentiels - tout ce qui est supérieur ou égal à 10. Comparez cela avec l'autre cas (i! = 10); il n'attrape qu'un seul cas de sortie possible - lorsque i est exactement 10.

Un sous-produit de cela est qu'il améliore la lisibilité. De plus, si l'incrément est différent de 1, cela peut aider à minimiser la probabilité d'un problème si nous commettons une erreur lors de l'écriture du cas de fermeture.

Considérer:

1) for (i = 1; i < 14; i+=2)

2) for (i = 1; i != 14; i+=2)

Bien que les deux cas soient probablement défectueux / incorrects, le second est probablement plus faux car il ne s'arrêtera pas. Le premier cas se fermera, et il y a plus de chances qu'il s'arrête au bon endroit, même si 14 est probablement le mauvais numéro (15 serait probablement mieux).

Voici une autre réponse que personne ne semble avoir encore trouvée. forles boucles doivent être utilisées lorsque vous devez parcourir une séquence . L'utilisation !=est la méthode la plus concise pour énoncer la condition de fin de la boucle. Cependant, l'utilisation d'un opérateur moins restrictif est un idiome de programmation défensive très courant. Pour les entiers, cela n'a pas d'importance - c'est juste un choix personnel sans exemple plus spécifique. Boucler les collections avec les itérateurs que vous souhaitez utiliser !=pour les raisons que d'autres ont indiquées. Si vous envisagez des séquences de floatou double, alors vous voulez éviter !=à tout prix.

Ce que je voulais souligner, c'est qu'il forest utilisé lorsque vous avez besoin d'itérer sur une séquence. La séquence générée a un point de départ, un intervalle et une condition de fin. Ceux-ci sont spécifiés de manière concise dans la fordéclaration. Si vous vous trouvez soit (1) n'incluant pas la partie étape du forou (2) spécifiant quelque chose comme truela condition de garde, alors vous ne devriez pas utiliser de forboucle!

La whileboucle est utilisée pour poursuivre le traitement lorsqu'une condition spécifique est remplie. Si vous ne traitez pas une séquence, vous voudrez probablement une whileboucle à la place. Les arguments de la condition de garde sont similaires ici, mais la décision entre a whileet une forboucle doit être très consciente. La whileboucle est sous-estimée dans les cercles C ++ IMO.

Si vous fortraitez une collection d'éléments (une utilisation très courante en boucle), vous devriez vraiment utiliser une méthode plus spécialisée. Malheureusement, std::for_eachc'est assez douloureux en C ++ pour un certain nombre de raisons. Dans de nombreux cas, séparer le corps d'une forboucle dans une fonction autonome (bien que quelque peu douloureuse) donne une solution beaucoup plus propre. Lorsque l'on travaille avec des collections, pensez std::for_each, std::transformou std::accumulate. La mise en œuvre de nombreux algorithmes devient concise et limpide lorsqu'elle est exprimée de cette manière. Sans oublier que l'isolement du corps de la boucle dans une fonction / méthode séparée vous oblige à vous concentrer sur l'algorithme, ses exigences d'entrée et ses résultats.

Si vous utilisez Java, Python, Ruby ou même C ++ 0x , vous devez alors utiliser une boucle foreach de collecte appropriée . Au fur et à mesure que les compilateurs C ++ implémentent cette fonctionnalité, un certain nombre de forboucles disparaîtront, tout comme ces types de discussions.

Utiliser "moins de" est (généralement) sémantiquement correct, vous voulez vraiment dire que compter jusqu'à in'est plus inférieur à 10, donc "moins de" exprime clairement vos intentions. L'utilisation de "non égal" fonctionne évidemment dans des cas d'appels virtuels, mais donne une signification légèrement différente. Dans certains cas, c'est peut-être ce dont vous avez besoin, mais d'après mon expérience, cela n'a jamais été le cas. Si vous aviez vraiment un cas où il ipourrait y avoir plus ou moins de 10 mais que vous voulez continuer à boucler jusqu'à ce qu'il soit égal à 10, alors ce code aurait vraiment besoin de commenter très clairement, et pourrait probablement être mieux écrit avec une autre construction, comme en tant que whileboucle peut-être.

L'une des raisons pour lesquelles je préférerais un less thansur un not equalsest d'agir comme gardien. Dans certaines circonstances limitées (mauvaise programmation ou désinfection), cela not equalspourrait être ignoré alors qu'il less thanserait toujours en vigueur.

Voici un exemple où l'absence d'un contrôle de désinfection a conduit à des résultats étranges: http://www.michaeleisen.org/blog/?p=358

Voici une raison pour laquelle vous préféreriez peut-être utiliser <plutôt que !=. Si vous utilisez un langage qui a une portée globale de variable, que se passe-t-il si un autre code est modifié i? Si vous utilisez <plutôt que !=, le pire qui se passe est que l'itération se termine plus rapidement: peut-être d'autres incréments de code ipar accident, et vous sautez quelques itérations dans la boucle for. Mais que se passe-t-il si vous bouclez de 0 à 10, que la boucle arrive à 9 et que certains incréments de thread sont mal écrits ipour une raison étrange. Ensuite, votre boucle termine cette itération et incrémente de isorte que la valeur soit maintenant 11. Comme la boucle a ignoré la condition de sortie ( ijamais égale à 10), elle va maintenant boucler infiniment.

Cela ne doit pas nécessairement être une logique de type threading-and-global-variables particulièrement bizarre qui provoque cela. Il se peut que vous écriviez une boucle qui doit revenir en arrière. Si vous mutez ià l'intérieur de la boucle et que vous bousillez votre logique, la faire en sorte qu'elle ait une limite supérieure plutôt qu'un a !=est moins susceptible de vous laisser dans une boucle infinie.

Dans le monde embarqué, en particulier dans les environnements bruyants, vous ne pouvez pas compter sur la RAM se comportant nécessairement comme il se doit. Dans une conditionnelle (pour, tandis que, si) où vous comparez en utilisant '==' ou '! =' Vous courez toujours le risque que vos variables sautent cette valeur cruciale qui termine la boucle - cela peut avoir des conséquences désastreuses - Mars Lander conséquences de niveau. L'utilisation de «<» ou «>» dans la condition fournit un niveau de sécurité supplémentaire pour attraper les «inconnues inconnues».

Dans l'exemple d'origine, si elles iétaient inexplicablement catapultées à une valeur bien supérieure à 10, la comparaison '<' intercepterait l'erreur immédiatement et quitterait la boucle, mais '! =' Continuerait à compter jusqu'à ce qu'elle soit ienroulée autour de 0 et retour au 10.