Les boucles «while (true)» sont-elles si mauvaises? [fermé]


218

Je programme en Java depuis plusieurs années maintenant, mais je suis récemment retourné à l'école pour obtenir un diplôme officiel. J'ai été assez surpris d'apprendre que, lors de ma dernière mission, j'ai perdu des points pour avoir utilisé une boucle comme celle ci-dessous.

do{
     //get some input.
     //if the input meets my conditions, break;
     //Otherwise ask again.
} while(true)

Maintenant, pour mon test, je suis juste en train de rechercher des entrées de console, mais on m'a dit que ce type de boucle est déconseillé parce que l'utilisation breaks'apparente à goto, nous ne le faisons tout simplement pas.

Je comprends parfaitement les pièges de gotoet son cousin Java break:label, et j'ai le bon sens de ne pas les utiliser. Je me rends également compte qu'un programme plus complet fournirait d'autres moyens d'évasion, par exemple pour simplement mettre fin au programme, mais ce n'était pas une raison que mon professeur a citée, alors ...

Qu'est-ce qui ne va pas do-while(true)?


23
Demandez à votre professeur, ce genre de choses est assez subjectif.
Chris Eberle

18
J'ai trouvé cet article utile pour comprendre ce qui est nocif à propos de goto . La comparaison avec breakest probablement bien intentionnée, mais en fait mal comprise. Vous pouvez peut-être éduquer votre professeur à ce sujet;) D'après mon expérience, les professeurs ne connaissent pas grand-chose à l'art de la programmation.
Magnus Hoff

100
La seule mauvaise chose vraiment, incontestable à ce sujet, est dans mon esprit, le fait que do {} while (true)c'est équivalent à while(true) {}et ce dernier est de loin la forme la plus conventionnelle et beaucoup plus claire.
Voo

11
Si quelqu'un n'apprécie pas le pouvoir expressif simple de break, il devrait essayer de programmer dans un langage sans lui. Cela ne prend pas trop de boucles avant que vous ne le souhaitiez!
Steven

16
Je ne suis pas d'accord avec l'étiquette de devoirs.
aaaa bbbb

Réponses:


220

Je ne dirais pas que c'est mauvais - mais je chercherais normalement au moins une alternative.

Dans les situations où c'est la première chose que j'écris, j'essaie presque toujours au moins de la refactoriser en quelque chose de plus clair. Parfois, cela ne peut pas être aidé (ou l'alternative est d'avoir une boolvariable qui n'a rien de significatif, sauf indiquer la fin de la boucle, moins clairement qu'une breakdéclaration), mais cela vaut au moins la peine d'essayer.

Comme exemple d'utilisation plus claire breakqu'un indicateur, considérez:

while (true)
{
    doStuffNeededAtStartOfLoop();
    int input = getSomeInput();
    if (testCondition(input))
    {
        break;
    }
    actOnInput(input);
}

Maintenant, forçons-le à utiliser un drapeau:

boolean running = true;
while (running)
{
    doStuffNeededAtStartOfLoop();
    int input = getSomeInput();
    if (testCondition(input))
    {
        running = false;
    }
    else
    {
        actOnInput(input);
    }
}

Je considère ce dernier comme plus compliqué à lire: il y a un elsebloc supplémentaire , il actOnInputest plus en retrait, et si vous essayez de comprendre ce qui se passe lors des testConditionretours true, vous devez regarder attentivement le reste du bloc pour vérifier qu'il y a n'est pas quelque chose après le elsebloc qui se produirait, qu'il runningait été défini falseou non.

La breakdéclaration communique plus clairement l'intention et permet au reste du bloc de poursuivre ce qu'il doit faire sans se soucier des conditions antérieures.

Notez que c'est exactement le même type d'argument que les gens ont à propos de plusieurs instructions de retour dans une méthode. Par exemple, si je peux déterminer le résultat d'une méthode dans les premières lignes (par exemple parce qu'une entrée est nulle, ou vide, ou zéro), je trouve plus clair de renvoyer cette réponse directement que d'avoir une variable pour stocker le résultat , puis un bloc entier d'autres codes, et enfin une returndéclaration.


3
Je suis d'accord que ce n'est pas le premier outil auquel j'atteins, mais il semble que le problème soit résolu si proprement, et j'aime le code propre.
JHarnach

3
@ X-Zero: Oui, parfois. Si vous pouvez transformer la "pause" en un "retour", c'est souvent de la bonté ... même si vous pourriez toujours vous retrouver avec unwhile (true)
Jon Skeet

21
@trutheality: je préfère que la plupart de mon code soit aussi indenté que possible. Et une condition avec une affectation composée me semble plus compliquée.
Jon Skeet

3
@Vince: Oui, et c'est génial si vous pouvez exprimer facilement la condition au début de la boucle . Mais parfois, vous ne pouvez pas - et c'est la situation dont nous parlons. Veuillez noter les deux premières phrases de ma réponse.
Jon Skeet

6
@Ismail: J'espère que non. Les articles doivent être jugés uniquement sur leur contenu et non sur l'auteur. Heck, je voterais même contre un article d'Eric Lippert si je pensais qu'il était inexact / inutile. Mais cela n'est pas encore arrivé :)
Jon Skeet

100

AFAIK rien, vraiment. Les enseignants sont allergiques goto, car ils ont entendu quelque part que c'était vraiment mauvais. Sinon, vous écririez simplement:

bool guard = true;
do
{
   getInput();
   if (something)
     guard = false;
} while (guard)

C'est presque la même chose.

C'est peut-être plus propre (car toutes les informations de bouclage sont contenues en haut du bloc):

for (bool endLoop = false; !endLoop;)
{

}

4
J'aime vos suggestions car la condition de terminaison est beaucoup plus visible. Cela signifie qu'en lisant le code, vous comprendrez plus tôt ce qu'il essaie de faire. Je n'utiliserais jamais une boucle infinie mais j'utilise fréquemment vos deux versions.
Traîneau le

4
Le consensus est qu'un drapeau vaut mieux que de se casser en grande partie parce qu'il exprime une intention? Je peux voir que c'est bénéfique. Toutes les bonnes réponses, mais je marquerai cela comme accepté
JHarnach

20
Les deux souffrent toujours de la pollution du reste de la boucle (dans certaines situations au moins) en continuant à aller jusqu'au bout du corps de la boucle même si vous savez que vous vous cassez . Je vais mettre un exemple dans ma réponse ...
Jon Skeet

8
J'aime mieux la réponse de Jon Skeet. Aussi, alors que (vrai) {} est BEAUCOUP mieux que faire {} tandis que (vrai)
aaaa bbbb

1
Je déteste que Dijkstra ait jamais écrit cet article GoTo. Bien que GoTo puisse certainement avoir été abusé dans le passé, cela ne signifie pas que vous ne devriez jamais l'utiliser. En outre, Exit For, Break, Exit While, Try / Catch ne sont que des formes spécialisées de Goto. Gotos peut souvent rendre le code plus lisible. Et oui, je suis conscient que tout peut être fait sans Goto. Cela ne signifie pas que cela devrait.
Kibbee

39

Douglas Crockford a fait une remarque sur la façon dont il souhaitait que JavaScript contienne une loopstructure:

loop
{
  ...code...
}

Et je ne pense pas que Java serait pire pour avoir une loopstructure non plus.

Il n'y a rien d' intrinsèquement mauvais avec des while(true)boucles, mais il est une tendance pour les enseignants de les décourager. Du point de vue de l'enseignement, il est très facile de demander aux élèves de créer des boucles sans fin et de ne pas comprendre pourquoi la boucle ne s'échappe jamais.

Mais ce qu'ils mentionnent rarement, c'est que tous les mécanismes de boucle peuvent être répliqués avec des while(true)boucles.

while( a() )
{
  fn();
}

est le même que

loop
{
  if ( !a() ) break;
  fn();
}

et

do
{
  fn();
} while( a() );

est le même que:

loop
{
  fn();
  if ( !a() ) break;
}

et

for ( a(); b(); c() )
{
  fn();
}

est le même que:

a();
loop
{
  if ( !b() ) break;
  fn();
  c();
}

Tant que vous pouvez configurer vos boucles d'une manière qui fonctionne, la construction que vous choisissez d'utiliser n'a pas d'importance. Si cela se trouve dans une forboucle, utilisez une forboucle.

Une dernière partie: gardez vos boucles simples. S'il y a beaucoup de fonctionnalités qui doivent se produire à chaque itération, mettez-la dans une fonction. Vous pouvez toujours l'optimiser après l'avoir fait fonctionner.


2
+1: Il existe des complexités supplémentaires avec les forboucles lorsque des continueinstructions sont impliquées, mais elles ne constituent pas une extension majeure.
Donal Fellows

J'utilise généralement une boucle for quand il y a une séquence que je veux parcourir et une boucle while quand il y a une condition que je veux remplir. Cela rend le code imo plus lisible.
dascandy

4
Personne n'écrit for (;;) {plus? (Prononcé "pour toujours"). C'était très populaire auparavant.
Dawood ibn Kareem

16

En 1967, Edgar Dijkstra a écrit un article dans un magazine spécialisé expliquant pourquoi goto devrait être éliminé des langages de haut niveau pour améliorer la qualité du code. Tout un paradigme de programmation appelé "programmation structurée" en est sorti, bien que tout le monde ne soit certainement pas d'accord pour dire que goto signifie automatiquement un mauvais code.

Le nœud de la programmation structurée est essentiellement que la structure du code devrait déterminer son flux plutôt que d'avoir des gotos ou des ruptures ou continue de déterminer le flux, dans la mesure du possible. De même, avoir plusieurs points d'entrée et de sortie dans une boucle ou une fonction est également déconseillé dans ce paradigme.

Évidemment, ce n'est pas le seul paradigme de programmation, mais souvent il peut être facilement appliqué à d'autres paradigmes comme la programmation orientée objet (ala Java).

Vos professeurs ont probablement été formés et essaient d'enseigner à votre classe que nous éviterions au mieux le "code spaghetti" en nous assurant que notre code est structuré et en suivant les règles implicites d'une programmation structurée.

Bien qu'il n'y ait rien de fondamentalement "mauvais" avec une implémentation qui utilise break, certains considèrent qu'il est beaucoup plus facile de lire du code où la condition pour la boucle est explicitement spécifiée dans la condition while (), et élimine certaines possibilités d'être trop délicat. Il y a certainement des pièges à utiliser une condition while (true) qui semble apparaître fréquemment dans le code par des programmeurs novices, comme le risque de créer accidentellement une boucle infinie, ou de rendre le code difficile à lire ou déroutant inutilement.

Ironiquement, la gestion des exceptions est un domaine où des écarts par rapport à la programmation structurée seront certainement attendus à mesure que vous progressez dans la programmation en Java.

Il est également possible que votre instructeur s'attende à ce que vous démontriez votre capacité à utiliser une structure de boucle ou une syntaxe particulière enseignée dans ce chapitre ou cette leçon de votre texte, et bien que le code que vous avez écrit soit fonctionnellement équivalent, vous n'avez peut-être pas démontré la compétence particulière que vous étiez censé apprendre dans cette leçon.


2
Voici l'article d'Edsger Dijkstra . C'est une bonne lecture.
Roy Prins

14

La convention Java usuelle pour la lecture des entrées est la suivante:

import java.io.*;
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String strLine;

while ((strLine = br.readLine()) != null) {
  // do something with the line
}

Et la convention C ++ habituelle pour lire les entrées est:

#include <iostream>
#include <string>
std::string data;
while(std::readline(std::cin, data)) {
  // do something with the line
}

Et en C, c'est

#include <stdio.h>
char* buffer = NULL;
size_t buffer_size;
size_t size_read;
while( (size_read = getline(&buffer, &buffer_size, stdin)) != -1 ){
  // do something with the line
}
free(buffer);

ou si vous êtes convaincu que vous connaissez la longueur de la plus longue ligne de texte de votre fichier, vous pouvez le faire

#include <stdio.h>
char buffer[BUF_SIZE];
while (fgets(buffer, BUF_SIZE, stdin)) {
  //do something with the line
}

Si vous testez pour voir si votre utilisateur a entré une quitcommande, il est facile d'étendre l'une de ces 3 structures de boucle. Je vais le faire en Java pour vous:

import java.io.*;
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String line;

while ((line = br.readLine()) != null  && !line.equals("quit") ) {
  // do something with the line
}

Donc, bien qu'il y ait certainement des cas où breakou gotoest justifié, si tout ce que vous faites est de lire un fichier ou la console ligne par ligne, vous ne devriez pas avoir besoin d'une while (true)boucle pour l'accomplir - votre langage de programmation vous a déjà fourni avec un idiome approprié pour utiliser la commande d'entrée comme condition de boucle.


En fait, si vous utilisez une while (true)boucle au lieu d'une de ces boucles d'entrée conventionnelles, vous oubliez peut-être de vérifier la fin du fichier.
Ken Bloom

3
Vous accomplissez cela efficacement en insérant la première partie de la boucle dans le whileconditionnel. Dans la dernière condition Java, cela devient déjà assez lourd, et si vous avez dû faire une manipulation approfondie pour décider de continuer ou non, cela peut devenir assez long. Vous pouvez le diviser en une fonction distincte, et cela pourrait être mieux. Mais si vous le voulez dans une seule fonction, et qu'il y a un travail non trivial à faire avant de décider de continuer, c'est while(true)peut-être mieux.
poolie

@poolie: Dans ce cas, il est probablement préférable d'utiliser la commande read comme condition de boucle (qui vérifie EOF) et de rechercher vos autres conditions à l'intérieur de la boucle en tant qu'instructions break.
Ken Bloom

1
Pour ce que ça vaut, ce gets()n'est pas une convention commune. Il est très propice aux débordements de tampon. fgets(buffer, BUFFER_SIZE, file)ressemble beaucoup plus à la pratique standard.
Dave

@Dave: J'ai maintenant édité la réponse à utiliser fgets.
Ken Bloom

12

Ce n'est pas une chose si terrible, mais vous devez prendre en compte les autres développeurs lors du codage. Même à l'école.

Vos collègues développeurs devraient pouvoir voir la clause de sortie de votre boucle, lors de la déclaration de boucle. Tu n'as pas fait ça. Vous avez caché la clause de sortie au milieu de la boucle, ce qui rend plus de travail pour quelqu'un d'autre qui vient et essaie de comprendre votre code. C'est la même raison pour laquelle des choses comme la «pause» sont évitées.

Cela étant dit, vous verrez toujours des choses comme ça dans BEAUCOUP de code dans le monde réel.


4
Si la boucle commence par, while (true)il est assez évident qu'il y aura un breakou à l' returnintérieur, ou qu'il fonctionnera pour toujours. Être simple est important, mais while(true)n'est pas particulièrement mauvais en soi. Les variables qui ont des invariants complexes sur les itérations de boucle seraient un exemple de quelque chose qui cause beaucoup plus d'angoisse.
poolie

4
Essayez d'aller à trois niveaux dans une recherche, puis de vous échapper. Le code va être bien pire si vous ne revenez pas seulement de ce point.
dascandy

11

C'est ton arme, ta balle et ton pied ...

C'est mauvais parce que vous demandez des ennuis. Ce ne sera pas vous ou l'une des autres affiches de cette page qui avez des exemples de boucles while courtes / simples.

Le problème commencera à un moment très aléatoire dans le futur. Cela peut être causé par un autre programmeur. Il peut s'agir de la personne qui installe le logiciel. Ce pourrait être l'utilisateur final.

Pourquoi? J'ai dû découvrir pourquoi une application LOC 700K commencerait progressivement à graver 100% du temps CPU jusqu'à ce que chaque CPU soit saturé. C'était une boucle while (true) incroyable. C'était gros et méchant, mais cela se résumait à:

x = read_value_from_database()
while (true) 
 if (x == 1)
  ...
  break;
 else if (x ==2)
  ...
  break;
and lots more else if conditions
}

Il n'y avait pas de dernière branche else. Si la valeur ne correspond pas à une condition if, la boucle continue de fonctionner jusqu'à la fin du temps.

Bien sûr, le programmeur a accusé les utilisateurs finaux de ne pas avoir choisi une valeur attendue par le programmeur. (J'ai ensuite éliminé toutes les instances de while (true) dans le code.)

À mon humble avis, ce n'est pas une bonne programmation défensive d'utiliser des constructions comme while (true). Il reviendra vous hanter.

(Mais je me souviens que les professeurs se sont classés si nous ne commentions pas chaque ligne, même pour i ++;)


3
+1 pour le commentaire sur la programmation défensive.
JHarnach

3
Dans votre exemple, le code est stupide non pas à cause du choix du while (true) mais à cause de l'idée de mettre une boucle autour du code.
Florian F

En effet, quel était l'intérêt de cette boucle? :)
juzzlin

6

C'est mauvais dans le sens où les constructions de programmation structurées sont préférées aux instructions break et continue (quelque peu non structurées). Ils sont, par comparaison, préférés à "goto" selon ce principe.

Je recommanderais toujours de rendre votre code aussi structuré que possible ... même si, comme le souligne Jon Skeet, ne le rendez pas plus structuré que cela!


5

D'après mon expérience, dans la plupart des cas, les boucles ont la condition "principale" de continuer. C'est la condition qui doit être écrite dans l'opérateur while () lui-même. Toutes les autres conditions qui peuvent rompre la boucle sont secondaires, moins importantes, etc. Elles peuvent être écrites comme des if() {break}instructions supplémentaires .

while(true) est souvent déroutant et moins lisible.

Je pense que ces règles ne couvrent pas 100% des cas mais probablement seulement 98% d'entre eux.


Bien dit. C'est comme utiliser une boucle for avec: while (true) {i ++; ...}. Vous enterrez la condition de boucle à l'intérieur de la boucle plutôt que dans la «signature».
LegendLength

3

Bien que ce ne soit pas nécessairement une réponse à pourquoi ne pas utiliser while (true), j'ai toujours trouvé cette déclaration de l'auteur comique et accompagnant une explication succincte de pourquoi faire tout au lieu de faire tout.

En ce qui concerne votre question: il n'y a pas de problème inhérent avec

while(true) {
   do_stuff();
   if(exit_time) {
      break;
   }
}

... si vous savez ce que vous faites et assurez-vous que cela exit_timesera évalué à un moment donné true.

Les enseignants vous découragent d'utiliser while(true)car jusqu'à ce que et à moins que vous ne sachiez exactement ce que vous faites, c'est un moyen facile de faire une erreur critique.


Je pense que le réglage exit_time = false; while(!exit_time) { execute_stuff(); }et do { execute_stuff(); } while(! exit_time );sont à la fois beaucoup plus clair que d'avoir un if( condition ) { break; }à la fin d'une boucle avec un while(true). Les coupures sont des courts-circuits aux boucles - parfaitement bien lorsqu'il est utilisé comme court-circuit au milieu d'une boucle, mais vous devez simplement évaluer une condition dans l'instruction while par rapport à une coupure à la fin d'une boucle.
dr jimbob

En ce qui concerne cette bande dessinée: alors que do-while ne peut pas faire tout ce qui peut être fait, do-while est parfois préférable de faire ce que do-while peut faire, même si cela peut aussi faire.
Theraot

3

Vous pouvez simplement utiliser un indicateur booléen pour indiquer quand terminer la boucle while. Breaket go toétaient des raisons pour lesquelles les logiciels étaient trop difficiles à maintenir - la crise des logiciels (tm) - et devraient être évités, et peuvent facilement l'être aussi.

C'est une question de savoir si vous êtes pragmatique ou non. Les codeurs pragmatiques pourraient simplement utiliser la pause dans cette situation simple.

Mais il est bon d'avoir l'habitude de ne pas les utiliser, sinon vous pouvez les utiliser hors d'habbit dans des situations inappropriées, comme dans les boucles imbriquées compliquées où la lisibilité et la maintenabilité de votre code deviennent plus difficiles à utiliser break.


8
Parce que garder un drapeau booléen n'est probablement pas plus clair, et pourrait bien être moins clair, selon mon expérience?
Jon Skeet

3
@ Jon Skeet Eh bien, il s'agit d'aller avec un bon habbit ou de s'entraîner mal en utilisant break. Un bool appelé "courir" ne vous est pas clair? C'est évident, facile à déboguer, et comme je l'ai mentionné précédemment, un bon habbit est une bonne chose à garder. Où est le problème?
Daniel Leschkowski

4
Un booléen appelé running qui m'oblige ensuite à en avoir un if (running)dans la boucle, indentant tout le reste du code quand tout ce que je veux, c'est de quitter la boucle est définitivement moins clair pour moi qu'une simple instruction break qui indique exactement ce que je veux faire. Vous semblez considérer l'utilisation de la pause comme une mauvaise habitude de façon axiomatique - je n'y pense pas en tant que telle.
Jon Skeet

2
Pourquoi auriez-vous un if (en cours d'exécution) dans la boucle? Comme avec break à la fin de la boucle, vous vérifiez si vous voulez casser et retourner le drapeau au lieu d'utiliser break et utiliser le drapeau dans while (en cours d'exécution) au lieu de while (true). Je ne comprends pas votre point, sérieusement. Je serais d'accord qu'un codeur pragmatique pourrait utiliser la pause dans certaines situations, mais je n'ai vraiment pas les commentaires que vous avez faits dans ma suggestion
Daniel Leschkowski

3
Vous supposez que vous n'avez rien à faire dans la boucle après avoir décidé de quitter ou non. Par exemple, dans la situation du PO, il doit demander plus d'informations s'il ne quitte pas.
Jon Skeet

3

Peut-être que je n'ai pas de chance. Ou peut-être que je manque simplement d'expérience. Mais chaque fois que je me souviens avoir traité d' while(true)avoir à l' breakintérieur, il était possible d'améliorer le code appliquant la méthode d'extraction à while-block , qui a conservé le while(true)mais (par coïncidence?) Transformé tous les breaks en returns.

D'après mon expérience, les while(true)pauses (c'est-à-dire avec retours ou lancers) sont assez confortables et faciles à comprendre.


  void handleInput() {
      while (true) {
          final Input input = getSomeInput();
          if (input == null) {
              throw new BadInputException("can't handle null input");
          }
          if (input.isPoisonPill()) {
              return;
          }
          doSomething(input);
      }
  }

3

Je pense que oui c'est assez mauvais ... ou du moins, pour de nombreux développeurs. C'est symptomatique des développeurs qui ne pensent pas à leurs conditions de boucle. Par conséquent, il y a des erreurs.


2

Il n'y a pas de problème majeur while(true)avecbreak instructions, mais certains peuvent penser que cela diminue légèrement la lisibilité du code. Essayez de donner aux variables des noms significatifs, évaluez les expressions au bon endroit.

Pour votre exemple, il semble beaucoup plus clair de faire quelque chose comme:

do {
   input = get_input();
   valid = check_input_validity(input);    
} while(! valid)

Cela est particulièrement vrai si la boucle do while devient longue - vous savez exactement où la vérification pour voir s'il y a une itération supplémentaire se produit. Toutes les variables / fonctions ont des noms appropriés au niveau de l'abstraction. lewhile(true) déclaration ne vous dit que le traitement n'est pas à l'endroit que vous pensiez.

Peut-être que vous voulez une sortie différente la deuxième fois dans la boucle. Quelque chose comme

input = get_input();
while(input_is_not_valid(input)) {
    disp_msg_invalid_input();
    input = get_input();
}

me semble alors plus lisible

do {
    input = get_input();
    if (input_is_valid(input)) {
        break;
    }
    disp_msg_invalid_input();
} while(true);

Encore une fois, avec un exemple trivial, les deux sont tout à fait lisibles; mais si la boucle est devenue très grande ou profondément imbriquée (ce qui signifie que vous devriez probablement déjà avoir refactorisé), le premier style peut être un peu plus clair.


1

J'utilise quelque chose de similaire, mais avec une logique opposée, dans beaucoup de mes fonctions.

DWORD dwError = ERROR_SUCCESS;

do
{
    if ( (dwError = SomeFunction()) != ERROR_SUCCESS )
    {
         /* handle error */
         continue;
    }

    if ( (dwError = SomeOtherFunction()) != ERROR_SUCCESS )
    {
         /* handle error */
         continue;
    }
}
while ( 0 );

if ( dwError != ERROR_SUCCESS )
{
    /* resource cleanup */
}

1

C'est plus une question d'esthétique, beaucoup plus facile à lire du code où vous savez explicitement pourquoi la boucle s'arrêtera juste dans la déclaration de la boucle.


1

Je dirais qu'en général, la raison pour laquelle ce n'est pas considéré comme une bonne idée est que vous n'utilisez pas la construction à son plein potentiel. De plus, j'ai tendance à penser que beaucoup d'instructeurs de programmation n'aiment pas que leurs étudiants arrivent avec des «bagages». Je veux dire par là que je pense qu'ils aiment être la principale influence sur le style de programmation de leurs étudiants. Alors peut-être que c'est juste une bête noire de l'instructeur.


1

Pour moi, le problème est la lisibilité.

Une instruction while avec une condition vraie ne vous dit rien sur la boucle. Cela rend le travail de compréhension beaucoup plus difficile.

Quoi de plus facile à comprendre à partir de ces deux extraits?

do {
  // Imagine a nice chunk of code here
} while(true);

do {
  // Imagine a nice chunk of code here
} while(price < priceAllowedForDiscount);

0

Je suppose qu'utiliser break pour votre professeur, c'est comme casser une branche d'arbre pour obtenir le fruit, utilisez d'autres astuces (inclinez la branche) pour obtenir le fruit et la branche est toujours en vie. :)


0

1) Rien de mal à un do -while(true)

2) Votre professeur a tort.

NSFS !!:

3) La plupart des enseignants sont des enseignants et non des programmeurs.


@Connell, attendez que votre professeur l'entende!
Pacerier

1
Je suis autodidacte sur le front de la programmation. Tout ce que je dois juger, c'est mon professeur d'informatique au secondaire, qui nous a appris à créer des sites Web en utilisant Dreamweaver de telle manière que TOUT était une div absolument positionnée ...
Connell

@Connell mon message pour montrer votre accord
Pacerier

2
"Ceux qui ne peuvent pas, enseignent." - C'est une assez grande généralisation, tu ne crois pas? Les médecins, ingénieurs, pilotes, etc. devraient-ils tous être autodidactes, car leurs instructeurs sont incompétents selon vous?
filip-fku

@ filip-fku wow wow ~ cool it cool it!
Pacerier

0

Cela peut être mauvais si votre boucle s'exécute sur un thread d'arrière-plan, donc lorsque vous fermez votre application en terminant un thread d'interface utilisateur, ce morceau de code continuera à s'exécuter. Comme d'autres l'ont déjà dit, vous devez toujours utiliser une sorte de chèque pour fournir un moyen d'annulation.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.