È una cattiva pratica usare l'interruzione in un ciclo for? [chiuso]

È una cattiva pratica usare l' breakistruzione all'interno di un forciclo ?

Dire, sto cercando un valore in un array. Confronta all'interno di un ciclo for e quando viene trovato il valore, break;per uscire dal ciclo for.

È una cattiva pratica? Ho visto l'alternativa utilizzata: definire una variabile vFounde impostarla su true quando il valore viene trovato e controllare vFoundla forcondizione dell'istruzione. Ma è necessario creare una nuova variabile proprio a questo scopo?

Sto chiedendo nel contesto di un normale ciclo C o C ++ for.

PS: Le linee guida di codifica MISRA sconsigliano l'uso di break.

Molte risposte qui, ma non ho ancora visto questo menzionato:

La maggior parte dei "pericoli" associati all'uso breako continuein un ciclo for vengono annullati se si scrivono cicli ordinati e facilmente leggibili. Se il corpo del tuo ciclo si estende su diverse lunghezze dello schermo e ha più sottoblocchi annidati, sì, potresti facilmente dimenticare che parte del codice non verrà eseguito dopo l'interruzione. Se, tuttavia, il ciclo è breve e pertinente, lo scopo dell'istruzione break dovrebbe essere ovvio.

Se un ciclo sta diventando troppo grande, utilizzare invece una o più chiamate di funzione ben denominate all'interno del ciclo. L'unico vero motivo per evitare di farlo è l'elaborazione dei colli di bottiglia.

No, la rottura è la soluzione corretta.

L'aggiunta di una variabile booleana rende il codice più difficile da leggere e aggiunge una potenziale fonte di errori.

Puoi trovare tutti i tipi di codice professionale con istruzioni "break". Ha perfettamente senso usarlo ogni volta che è necessario. Nel tuo caso questa opzione è migliore della creazione di una variabile separata solo allo scopo di uscire dal ciclo.

L'uso breakcosì come continuein un forciclo va perfettamente bene.

Semplifica il codice e ne migliora la leggibilità.

Lungi dalla cattiva pratica, Python (e altri linguaggi?) Ha esteso la struttura del forciclo in modo che una parte di essa verrà eseguita solo se il ciclo non lo fa break .

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

Produzione:

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

Codice equivalente senza breake pratico 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.')

Non c'è nulla di intrinsecamente sbagliato nell'usare un'istruzione break, ma i cicli annidati possono creare confusione. Per migliorare la leggibilità, molti linguaggi ( almeno Java lo fa ) supportano l'interruzione delle etichette che miglioreranno notevolmente la leggibilità.

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

Dirò che le istruzioni break (e return) spesso aumentano la complessità ciclomatica, il che rende più difficile dimostrare che il codice sta facendo la cosa corretta in tutti i casi.

Se stai pensando di utilizzare un'interruzione durante l'iterazione di una sequenza per un elemento particolare, potresti voler riconsiderare la struttura dei dati utilizzata per conservare i tuoi dati. Usare qualcosa come un Set o una Mappa può fornire risultati migliori.

break è un'istruzione completamente accettabile da usare (così è continue , btw). È tutta una questione di leggibilità del codice: finché non si hanno loop complicati e simili, va bene.

Non è come se fossero della stessa lega di goto . :)

Regola generale: se seguire una regola richiede di fare qualcosa di più imbarazzante e difficile da leggere quindi infrangere la regola, infrangere la regola.

Nel caso del looping finché non trovi qualcosa, ti imbatti nel problema di distinguere trovato e non trovato quando esci. Questo è:

for (int x=0;x<fooCount;++x)
{
  Foo foo=getFooSomehow(x);
  if (foo.bar==42)
    break;
}
// So when we get here, did we find one, or did we fall out the bottom?

Quindi va bene, puoi impostare un flag o inizializzare un valore "trovato" su null. Ma

Ecco perché in generale preferisco spingere le mie ricerche in funzioni:

Foo findFoo(int wantBar)
{
  for (int x=0;x<fooCount;++x)
  {
    Foo foo=getFooSomehow(x);
    if (foo.bar==wantBar)
      return foo;
  }
  // Not found
  return null;
}

Questo aiuta anche a liberare il codice. Nella riga principale, "find" diventa una singola istruzione e, quando le condizioni sono complesse, vengono scritte solo una volta.

Dipende dalla lingua. Anche se puoi eventualmente controllare una variabile booleana qui:

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

non è possibile farlo durante l'iterazione su un array:

for element in bigList: ...

Comunque, breakrenderebbe entrambi i codici più leggibili.

Nel tuo esempio non conosci il numero di iterazioni per il ciclo for . Perché non utilizzare invece il ciclo while , che consente al numero di iterazioni di essere indeterminato all'inizio?

Non è quindi necessario utilizzare break statemement in generale, poiché il ciclo può essere meglio definito come un ciclo while .

Sono d'accordo con altri che consigliano di utilizzare break. L'ovvia domanda consequenziale è perché qualcuno dovrebbe raccomandare diversamente? Bene ... quando usi break, salti il ​​resto del codice nel blocco e le iterazioni rimanenti. A volte questo causa bug, ad esempio:

• una risorsa acquisita nella parte superiore del blocco può essere rilasciata nella parte inferiore (questo vale anche per i blocchi all'interno dei forcicli), ma quel passaggio di rilascio può essere saltato accidentalmente quando un'uscita "prematura" è causata da breakun'istruzione (in "moderno" C ++, "RAII" viene utilizzato per gestire questo in modo affidabile e sicuro rispetto alle eccezioni: in pratica, i distruttori di oggetti liberano le risorse in modo affidabile indipendentemente da come si esce dall'ambito)

• qualcuno può modificare il test condizionale nella fordichiarazione senza accorgersi che esistono altre condizioni di uscita delocalizzate

• La risposta di ndim osserva che alcune persone potrebbero evitare breaks per mantenere un tempo di esecuzione del ciclo relativamente coerente, ma stavi confrontando breakcon l'uso di una variabile di controllo di uscita anticipata booleana dove ciò non vale

Ogni tanto le persone che osservano tali bug si rendono conto che possono essere prevenute / mitigate da questa regola "senza interruzioni" ... in effetti, esiste un'intera strategia correlata per una programmazione "più sicura" chiamata "programmazione strutturata", dove ogni funzione dovrebbe avere anche un unico punto di entrata e di uscita (cioè nessun goto, nessun ritorno anticipato). Può eliminare alcuni bug, ma senza dubbio ne introduce altri. Perché lo fanno?

• hanno un framework di sviluppo che incoraggia un particolare stile di programmazione / codice e hanno prove statistiche che questo produce un vantaggio netto in quel framework limitato, o
• sono stati influenzati dalle linee guida di programmazione o dall'esperienza in tale quadro, o
• sono solo idioti dittatoriali, o
• una delle precedenti + inerzia storica (rilevante in quanto le giustificazioni sono più applicabili al C rispetto al C ++ moderno).

È perfettamente valido da usare break- come altri hanno sottolineato, non è da nessuna parte nella stessa lega di goto.

Anche se potresti voler usare la vFoundvariabile quando vuoi controllare fuori dal ciclo se il valore è stato trovato nell'array. Anche dal punto di vista della manutenibilità, potrebbe essere utile avere un flag comune che segnali i criteri di uscita.

Ho fatto alcune analisi sulla base di codice su cui sto attualmente lavorando (40.000 righe di JavaScript).

Ho trovato solo 22 breakaffermazioni, di quelle:

• Sono state utilizzate 19 switchistruzioni all'interno (abbiamo solo 3 istruzioni switch in totale!).
• 2 sono stati utilizzati all'interno di forloop - un codice che ho immediatamente classificato come refactoring in funzioni separate e sostituito con returnstatement.
• Per quanto riguarda il ciclo breakinterno finale while... sono corso git blamea vedere chi ha scritto questa merda!

Quindi, secondo le mie statistiche: se breakviene utilizzato al di fuori di switch, è un odore di codice.

Ho anche cercato continuedichiarazioni. Nessuno trovato.

Non vedo alcun motivo per cui sarebbe una cattiva pratica A condizione che si desideri completare l'INTERRUZIONE dell'elaborazione a quel punto.

Nel mondo embedded, c'è molto codice là fuori che utilizza il seguente costrutto:

    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;

Questo è un esempio molto generico, molte cose stanno accadendo dietro le quinte, le interruzioni in particolare. Non usarlo come codice boilerplate, sto solo cercando di illustrare un esempio.

La mia opinione personale è che non c'è niente di sbagliato nello scrivere un loop in questo modo purché si prenda la dovuta cura per evitare di rimanere nel loop indefinitamente.

Dipende dal tuo caso d'uso. Ci sono applicazioni in cui il tempo di esecuzione di un ciclo for deve essere costante (ad esempio per soddisfare alcuni vincoli temporali o per nascondere i dati interni da attacchi basati sul tempo).

In questi casi avrà anche senso impostare un flag e controllare il valore del flag solo DOPO che tutte le foriterazioni del ciclo sono state effettivamente eseguite. Ovviamente, tutte le iterazioni del ciclo for devono eseguire codice che richiede ancora lo stesso tempo.

Se non ti interessa il tempo di esecuzione ... usa break;e continue;per rendere il codice più facile da leggere.

Sulle regole MISRA 98, che vengono utilizzate nella mia azienda in C dev, non deve essere utilizzata l'istruzione break

Modifica: l'interruzione è consentita in MISRA '04

Ovviamente, break;è la soluzione per fermare il ciclo for o il ciclo foreach. L'ho usato in php in foreach e for loop e ho trovato funzionante.

Non sono d'accordo!

Perché ignoreresti la funzionalità incorporata di un ciclo for per crearne uno tuo? Non è necessario reinventare la ruota.

Penso che abbia più senso avere i controlli nella parte superiore del ciclo for in questo modo

for(int i = 0; i < myCollection.Length && myCollection[i].SomeValue != "Break Condition"; i++)
{
//loop body
}

o se devi prima elaborare la riga

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
//loop body
}

In questo modo puoi scrivere una funzione per eseguire tutto e creare codice molto più pulito.

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

O se la tua condizione è complicata puoi spostare anche quel codice!

for(int i = 0; i < myCollection.Length && BreakFunctionCheck(i, myCollection); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

Il "codice professionale" che è pieno di interruzioni non mi suona come un codice professionale. Sembra una codifica pigra;)