I loop "while (true)" sono così negativi? [chiuso]

Sto programmando in Java da diversi anni, ma sono appena tornato a scuola per ottenere una laurea formale. Sono stato piuttosto sorpreso di apprendere che, durante il mio ultimo incarico, ho perso punti per l'utilizzo di un loop come quello sotto.

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

Ora per il mio test sto solo cercando l'input della console, ma mi è stato detto che questo tipo di loop è scoraggiato perché usare breakè simile a goto, semplicemente non lo facciamo.

Comprendo appieno le insidie ​​di gotosuo cugino Java break:labele ho il buon senso di non usarle. Mi rendo anche conto che un programma più completo fornirebbe altri mezzi di evasione, per esempio per terminare il programma, ma non è stato questo il motivo per cui il mio professore ha citato, quindi ...

Cosa c'è che non va do-while(true)?

Non direi che è male , ma ugualmente normalmente cerco almeno un'alternativa.

In situazioni in cui è la prima cosa che ho scrittura, ho quasi sempre almeno provo a refactoring in qualcosa di più chiaro. A volte non può essere aiutato (o l'alternativa è avere una boolvariabile che non fa nulla di significativo se non indicare la fine del ciclo, meno chiaramente di breakun'istruzione) ma vale la pena almeno provarci.

Come esempio di dove è più chiaro usare breakuna bandiera, considera:

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

Ora forziamolo a usare una bandiera:

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

Considero quest'ultimo più complicato da leggere: ha un elseblocco in più, actOnInputè più rientrato e se stai cercando di capire cosa succede quando testConditionritorna true, devi guardare attentamente il resto del blocco per verificare che ci sia non è qualcosa dopo il elseblocco che si verificherebbe se runningè stato impostato falseo meno.

La breakdichiarazione comunica l'intento in modo più chiaro e consente al resto del blocco di andare avanti con ciò che deve fare senza preoccuparsi delle condizioni precedenti.

Si noti che questo è esattamente lo stesso tipo di argomento che le persone hanno su più dichiarazioni di ritorno in un metodo. Ad esempio, se riesco a capire il risultato di un metodo all'interno delle prime poche righe (ad es. Perché alcuni input sono nulli, vuoti o zero) trovo più chiaro restituire quella risposta direttamente piuttosto che avere una variabile per memorizzare il risultato , poi un intero blocco di altro codice, e , infine, una returndichiarazione.

AFAIK niente, davvero. Gli insegnanti sono solo allergici goto, perché hanno sentito da qualche parte che è davvero brutto. Altrimenti dovresti semplicemente scrivere:

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

È quasi la stessa cosa.

Forse questo è più pulito (perché tutte le informazioni sul loop sono contenute nella parte superiore del blocco):

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

}

Douglas Crockford aveva un'osservazione su come desiderava che JavaScript contenesse una loopstruttura:

loop
{
  ...code...
}

E non penso che neanche Java sarebbe peggio per avere una loopstruttura.

Non c'è niente di intrinsecamente sbagliato con while(true)loop, ma non v'è una tendenza per gli insegnanti per scoraggiarli. Dal punto di vista dell'insegnamento, è molto facile avere gli studenti a creare loop infiniti e non capire perché il loop non sia mai sfuggito.

Ma ciò che raramente menzionano è che tutti i meccanismi di looping possono essere replicati con while(true)loop.

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

equivale a

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

e

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

equivale a:

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

e

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

equivale a:

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

Finché è possibile configurare i loop in un modo che funziona il costrutto che si sceglie di utilizzare non è importante. Se accade per adattarsi in un forciclo, utilizzare un forciclo.

Un'ultima parte: mantieni i tuoi loop semplici. Se ci sono molte funzionalità che devono accadere in ogni iterazione, mettile in una funzione. Puoi sempre ottimizzarlo dopo averlo fatto funzionare.

Nel 1967, Edgar Dijkstra scrisse un articolo in una rivista commerciale sul perché il goto dovesse essere eliminato da linguaggi di alto livello per migliorare la qualità del codice. Ne è scaturito un intero paradigma di programmazione chiamato "programmazione strutturata", sebbene certamente non tutti concordino sul fatto che goto significhi automaticamente codice errato.

Il punto cruciale della programmazione strutturata è essenzialmente che la struttura del codice dovrebbe determinare il suo flusso piuttosto che avere goto o interruzioni o continua a determinare il flusso, ove possibile. Allo stesso modo, avere più punti di entrata e uscita in un loop o in una funzione è scoraggiato in quel paradigma.

Ovviamente questo non è l'unico paradigma di programmazione, ma spesso può essere facilmente applicato ad altri paradigmi come la programmazione orientata agli oggetti (ala Java).

Probabilmente ai tuoi insegnanti è stato insegnato e sta cercando di insegnare alla tua classe che sarebbe meglio evitare lo "spaghetti code" assicurandoci che il nostro codice sia strutturato e seguendo le regole implicite della programmazione strutturata.

Sebbene non vi sia nulla di intrinsecamente "sbagliato" in un'implementazione che utilizza break, alcuni considerano significativamente più semplice leggere il codice in cui la condizione per il ciclo è esplicitamente specificata nella condizione while () ed elimina alcune possibilità di essere eccessivamente complicate. Ci sono sicuramente insidie ​​nell'usare una condizione while (true) che sembra comparire frequentemente nel codice da programmatori alle prime armi, come il rischio di creare accidentalmente un ciclo infinito o di rendere il codice difficile da leggere o che può essere inutilmente confuso.

Ironia della sorte, la gestione delle eccezioni è un'area in cui la deviazione dalla programmazione strutturata si presenterà sicuramente e ci si aspetterebbe mentre si avanza ulteriormente nella programmazione in Java.

È anche possibile che il tuo istruttore si sia aspettato che tu dimostrassi la tua capacità di usare una particolare struttura di loop o sintassi insegnata in quel capitolo o lezione del tuo testo, e mentre il codice che hai scritto è funzionalmente equivalente, potresti non aver dimostrato il abilità particolare che dovevi imparare in quella lezione.

L'usuale convenzione Java per la lettura dell'input è:

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

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

E la solita convenzione C ++ per la lettura dell'input è:

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

E in C, lo è

#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);

o se sei convinto di sapere quanto è lunga la riga di testo più lunga nel tuo file, puoi farlo

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

Se stai testando per vedere se il tuo utente ha inserito un quitcomando, è facile estendere una di queste 3 strutture a circuito. Lo farò in Java per te:

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
}

Quindi, mentre ci sono certamente casi in cui breako gotoè giustificato, se tutto ciò che stai facendo è leggere da un file o dalla console riga per riga, non dovresti aver bisogno di un while (true)ciclo per realizzarlo - il tuo linguaggio di programmazione ti ha già fornito con un linguaggio appropriato per l'utilizzo del comando input come condizione del loop.

Non è una cosa così terribile, ma devi prendere in considerazione altri sviluppatori durante la programmazione. Anche a scuola.

I tuoi colleghi sviluppatori dovrebbero essere in grado di vedere la clausola di uscita per il tuo ciclo, nella dichiarazione del ciclo. Non l'hai fatto. Hai nascosto la clausola exit nel mezzo del loop, facendo lavorare di più per qualcun altro che arriva e cerca di capire il tuo codice. Questo è lo stesso motivo per cui cose come "break" sono evitate.

Detto questo, vedrai ancora cose del genere in MOLTO codice nel mondo reale.

È la tua pistola, il tuo proiettile e il tuo piede ...

È male perché stai chiedendo problemi. Non sarai tu o nessuno degli altri poster in questa pagina ad avere esempi di cicli brevi / semplici.

Il problema inizierà in un momento molto casuale in futuro. Potrebbe essere causato da un altro programmatore. Potrebbe essere la persona che installa il software. Potrebbe essere l'utente finale.

Perché? Ho dovuto scoprire perché un'app LOC da 700 KB avrebbe iniziato a bruciare gradualmente il 100% del tempo della CPU fino a saturare ogni CPU. È stato un ciclo incredibile (vero). Era grosso e cattivo ma si riduceva a:

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

Non c'era nessun altro ramo finale. Se il valore non corrispondeva a una condizione if, il ciclo continuava a funzionare fino alla fine dei tempi.

Naturalmente, il programmatore ha accusato gli utenti finali di non aver scelto un valore che il programmatore si aspettava. (Ho quindi eliminato tutte le istanze di while (true) nel codice.)

IMHO non è una buona programmazione difensiva usare costrutti come while (true). Tornerà a perseguitarti.

(Ma ricordo che i professori hanno valutato se non abbiamo commentato ogni riga, anche per i ++;)

È un male, nel senso che i costrutti di programmazione strutturata sono preferiti alle (in qualche modo non strutturate) infrangere e continuare le dichiarazioni. Sono, al confronto, preferiti da "andare" secondo questo principio.

Consiglio sempre di rendere il tuo codice il più strutturato possibile ... anche se, come sottolinea Jon Skeet, non renderlo più strutturato di così!

Secondo la mia esperienza nella maggior parte dei casi, i loop hanno la condizione "principale" di continuare. Questa è la condizione che dovrebbe essere scritta nell'operatore while () stesso. Tutte le altre condizioni che possono interrompere il ciclo sono secondarie, non così importanti, ecc. Possono essere scritte come if() {break}istruzioni aggiuntive .

while(true) è spesso confuso ed è meno leggibile.

Penso che queste regole non coprano il 100% dei casi, ma probabilmente solo il 98% di questi.

Pur non essendo necessariamente una risposta al perché non usarlo while (true), ho sempre trovato questa dichiarazione dell'autore comico e accompagnatore una spiegazione sintetica sul perché fare mentre invece di fare.

Per quanto riguarda la tua domanda: non ci sono problemi inerenti

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

... se sai cosa stai facendo e assicurandoti che exit_timead un certo punto valuterà true.

Gli insegnanti ti scoraggiano dall'utilizzare while(true)perché fino a quando ea meno che tu non sappia esattamente cosa stai facendo, è un modo semplice per fare un errore critico.

Potresti semplicemente usare un flag booleano per indicare quando terminare il ciclo while. Breaked go toerano ragioni per cui il software era difficile da mantenere - la crisi del software (tm) - e dovrebbe essere evitato, e facilmente può esserlo anche.

È una domanda se sei pragmatico o no. I programmatori pragmatici potrebbero semplicemente usare l'interruzione in quella semplice situazione.

Ma è bene avere l'habbit di non usarli, altrimenti potresti usarli fuori dallo habbit in situazioni inadatte, come in loop nidificati complicati in cui la leggibilità e la manutenibilità del tuo codice diventano più difficili usando break.

Forse sono sfortunato. O forse mi manca solo un'esperienza. Ma ogni volta che ricordo di while(true)aver avuto a che fare con l' breakinterno, è stato possibile migliorare il codice applicando il metodo Extract a while-block , che ha mantenuto il while(true)(ma per coincidenza?) Trasformato tutte le breaks in returns.

Nella mia esperienza while(true)senza pause (cioè con rendimenti o tiri) sono abbastanza comodi e facili da capire.

  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);
      }
  }

Penso che sì, è piuttosto male ... o almeno, per molti sviluppatori. È sintomatico di sviluppatori che non pensano alle loro condizioni di loop. Di conseguenza c'è un errore soggetto a errori.

Non c'è nessun problema principale while(true)con breakle dichiarazioni, tuttavia alcuni possono pensare la sua abbassa leggermente la leggibilità del codice. Prova a dare alle variabili nomi significativi, valuta le espressioni nel posto giusto.

Per il tuo esempio, sembra molto più chiaro fare qualcosa del tipo:

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

Ciò è particolarmente vero se il ciclo do while si allunga: sai esattamente dove si verifica il controllo per verificare se si sta verificando un'iterazione aggiuntiva. Tutte le variabili / funzioni hanno nomi appropriati a livello di astrazione. L' while(true)affermazione fa è dirti che l'elaborazione non è nel posto che pensavi.

Forse vuoi un output diverso la seconda volta attraverso il loop. Qualcosa di simile a

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

mi sembra più leggibile allora

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

Ancora una volta, con un esempio banale entrambi sono abbastanza leggibili; ma se il loop diventa molto grande o profondamente annidato (il che significa che probabilmente dovresti già aver effettuato il refactoring), il primo stile potrebbe essere un po 'più chiaro.

Uso qualcosa di simile, ma con logica opposta, in molte delle mie funzioni.

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 */
}

È più una cosa estetica, molto più facile leggere il codice in cui sai esplicitamente perché il ciclo si fermerà proprio nella dichiarazione del ciclo.

Direi che generalmente la ragione per cui non è considerata una buona idea è che non stai usando il costrutto per il suo pieno potenziale. Inoltre, tendo a pensare che a molti istruttori di programmazione non piaccia quando i loro studenti entrano con "bagaglio". Voglio dire, penso che a loro piace essere l'influenza primaria sullo stile di programmazione dei loro studenti. Quindi forse è solo una piccola pipì dell'istruttore.

Per me, il problema è la leggibilità.

Un'istruzione while con una condizione vera non dice nulla sul ciclo. Rende il lavoro di comprensione molto più difficile.

Cosa sarebbe più facile da capire da questi due frammenti?

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

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

Immagino che usare la pausa per il tuo insegnante sia come spezzare un ramo di un albero per ottenere il frutto, usare altri trucchi (piega il ramo) in modo da ottenere il frutto e il ramo è ancora vivo :)

1) Non c'è niente di sbagliato in a do -while(true)

2) Il tuo insegnante ha torto.

NSFS !!:

3) La maggior parte degli insegnanti sono insegnanti e non programmatori.

Potrebbe essere negativo se il tuo ciclo viene eseguito su un thread in background, quindi quando chiudi l'applicazione terminando un thread dell'interfaccia utente, quel pezzo di codice continuerà a essere eseguito. Come altri hanno già detto, dovresti sempre usare una sorta di controllo per fornire un modo per la cancellazione.