`Break` e` continue` sono cattive pratiche di programmazione?

Il mio capo continua a menzionare con disinvoltura che i programmatori cattivi usano breake continuenei loop.

Li uso sempre perché hanno un senso; lascia che ti mostri l'ispirazione:

function verify(object) {
    if (object->value < 0) return false;
    if (object->value > object->max_value) return false;
    if (object->name == "") return false;
    ...
}

Il punto qui è che prima la funzione verifica che le condizioni siano corrette, quindi esegue la funzionalità effettiva. Lo stesso IMO si applica ai loop:

while (primary_condition) {
    if (loop_count > 1000) break;
    if (time_exect > 3600) break;
    if (this->data == "undefined") continue;
    if (this->skip == true) continue;
    ...
}

Penso che questo renda più semplice la lettura e il debug; ma non vedo nemmeno un aspetto negativo.

Se utilizzati all'inizio di un blocco, come i primi controlli effettuati, si comportano come precondizioni, quindi è buono.

Se usati nel mezzo del blocco, con un po 'di codice in giro, si comportano come trappole nascoste, quindi è male.

Puoi leggere il documento di Programmazione strutturata del 1974 di Donald Knuth con andare a Dichiarazioni , in cui discute vari usi di quelli go tostrutturalmente desiderabili. Includono l'equivalente di breake le continuedichiarazioni (molti degli usi di go toin sono stati sviluppati in costrutti più limitati). Il tuo capo è il tipo da chiamare Knuth un cattivo programmatore?

(Gli esempi forniti mi interessano. In genere, breake continuenon amano le persone a cui piacciono una voce e un'uscita da qualsiasi codice, e quel tipo di persona si acciglia anche di più returndichiarazioni.)

Non credo che siano cattivi. L'idea che siano cattivi viene dai giorni della programmazione strutturata. È correlato all'idea che una funzione deve avere un singolo punto di ingresso e un singolo punto di uscita, cioè solo uno returnper funzione.

Questo ha senso se la tua funzione è lunga e se hai più loop nidificati. Tuttavia, le tue funzioni dovrebbero essere brevi e dovresti avvolgere i circuiti e i loro corpi in funzioni brevi. Generalmente, forzare una funzione ad avere un singolo punto di uscita può comportare una logica molto contorta.

Se la tua funzione è molto breve, se hai un singolo loop o, nel peggiore dei casi, due loop nidificati e se il corpo del loop è molto breve, allora è molto chiaro cosa fa uno breako uno continue. È anche chiaro cosa fanno più returndichiarazioni.

Questi problemi vengono affrontati in "Codice pulito" di Robert C. Martin e in "Refactoring" di Martin Fowler.

I cattivi programmatori parlano in modo assoluto (proprio come Sith). I bravi programmatori usano la soluzione più chiara possibile (a parità di tutte le altre cose ).

L'uso frequente e continua spesso rende il codice difficile da seguire. Ma se sostituirli rende il codice ancora più difficile da seguire, allora è un brutto cambiamento.

L'esempio che hai dato è sicuramente una situazione in cui le interruzioni e le continue dovrebbero essere sostituite con qualcosa di più elegante.

Molte persone pensano che sia una cattiva idea perché il comportamento non è facilmente prevedibile. Se stai leggendo il codice e vedi while(x < 1000){}che supponi che funzionerà fino a x> = 1000 ... Ma se ci sono interruzioni nel mezzo, allora non è vero, quindi non puoi davvero fidarti del tuo looping ...

È lo stesso motivo per cui alle persone non piace GOTO: certo, può essere usato bene, ma può anche portare a un divino codice spaghetti, in cui il codice salta casualmente da una sezione all'altra.

Per quanto mi riguarda, se avessi fatto un ciclo che si era rotto su più di una condizione, avrei fatto while(x){}X su falso quando avevo bisogno di scoppiare. Il risultato finale sarebbe lo stesso e chiunque leggesse il codice saprebbe guardare più da vicino le cose che hanno cambiato il valore di X.

Sì, puoi [ri] scrivere programmi senza istruzioni di break (o ritorna dalla metà dei loop, che fanno la stessa cosa). Tuttavia, potrebbe essere necessario introdurre ulteriori variabili e / o duplicazione del codice, che in genere rendono il programma più difficile da comprendere. Pascal (il linguaggio di programmazione) è stato molto male soprattutto per i programmatori principianti per questo motivo. Il tuo capo vuole fondamentalmente che tu programmi nelle strutture di controllo di Pascal. Se Linus Torvalds fosse nei tuoi panni, probabilmente mostrerebbe al tuo capo il dito medio!

C'è un risultato informatico chiamato la gerarchia delle strutture di controllo di Kosaraju, che risale al 1973 e che è menzionata nel (più) famoso documento di Knuth sulle foto del 1974. (Questo documento di Knuth era già stato raccomandato sopra da David Thornley, tra l'altro .) Ciò che S. Rao Kosaraju ha dimostrato nel 1973 è che non è possibile riscrivere tutti i programmi che hanno interruzioni a più livelli di profondità n in programmi con profondità di interruzione inferiore a n senza introdurre variabili aggiuntive. Ma diciamo che è solo un risultato puramente teorico. (Basta aggiungere alcune variabili extra ?! Sicuramente puoi farlo per compiacere il tuo capo ...)

Ciò che è molto più importante dal punto di vista dell'ingegneria del software è un recente documento del 1995 di Eric S. Roberts intitolato Loop Exits and Structured Programming: Reopening the Debate ( http://cs.stanford.edu/people/eroberts/papers/SIGCSE- 1995 / LoopExits.pdf ). Roberts riassume diversi studi empirici condotti da altri prima di lui. Ad esempio, quando a un gruppo di studenti del tipo CS101 è stato chiesto di scrivere codice per una funzione che implementa una ricerca sequenziale in un array, l'autore dello studio ha dichiarato quanto segue su quegli studenti che hanno usato una pausa / return / goto per uscire da il ciclo di ricerca sequenziale quando è stato trovato l'elemento:

Devo ancora trovare una sola persona che ha tentato un programma usando [questo stile] che ha prodotto una soluzione errata.

Roberts afferma inoltre che:

Gli studenti che hanno tentato di risolvere il problema senza utilizzare un ritorno esplicito dal ciclo for sono andati molto meno bene: solo sette dei 42 studenti che hanno tentato questa strategia sono riusciti a generare soluzioni corrette. Tale cifra rappresenta un tasso di successo inferiore al 20%.

Sì, potresti essere più esperto degli studenti CS101, ma senza usare l'istruzione break (o equivalentemente restituire / andare dal centro dei loop), alla fine scriverai un codice che mentre nominalmente ben strutturato è abbastanza peloso in termini di logica aggiuntiva variabili e duplicazione del codice che qualcuno, probabilmente te stesso, inserirà in esso dei bug logici mentre cerca di seguire lo stile di codifica del tuo capo.

Dirò anche qui che l'articolo di Roberts è molto più accessibile al programmatore medio, quindi una prima lettura migliore di quella di Knuth. È anche più breve e copre un argomento più ristretto. Probabilmente potresti persino consigliarlo al tuo capo, anche se è il management piuttosto che il tipo CS.

Non prendo in considerazione l'utilizzo di nessuna di queste cattive pratiche, ma usarle troppo all'interno dello stesso loop dovrebbe giustificare un ripensamento della logica utilizzata nel loop. Usali con parsimonia.

L'esempio che hai fornito non necessita di interruzioni né continua:

while (primary-condition AND
       loop-count <= 1000 AND
       time-exec <= 3600) {
   when (data != "undefined" AND
           NOT skip)
      do-something-useful;
   }

Il mio "problema" con le 4 righe del tuo esempio è che sono tutte sullo stesso livello ma fanno cose diverse: alcune si interrompono, altre continuano ... Devi leggere ogni riga.

Nel mio approccio nidificato, più approfondisci, più il codice diventa "utile".

Ma, se dentro di te troverai un motivo per fermare il loop (diverso dalla condizione primaria), una pausa o un ritorno avrebbero bisogno. Preferirei questo rispetto all'uso di un flag aggiuntivo che deve essere testato nelle condizioni di massimo livello. L'interruzione / ritorno è più diretta; indica meglio l'intento che impostare un'altra variabile.

La "cattiveria" dipende da come li usi. In genere uso interruzioni nei costrutti di loop SOLO quando mi salveranno cicli che non possono essere salvati attraverso un refactoring di un algoritmo. Ad esempio, scorrere una raccolta in cerca di un elemento con un valore in una proprietà specifica impostato su true. Se tutto ciò che devi sapere è che una delle voci aveva questa proprietà impostata su true, una volta raggiunto quel risultato, una pausa è buona per terminare il loop in modo appropriato.

Se l'utilizzo di un'interruzione non renderà il codice specificamente più facile da leggere, più breve da eseguire o salvare i cicli nell'elaborazione in modo significativo, è meglio non usarli. Tendo a programmare il "minimo comune denominatore" quando possibile per assicurarmi che chiunque mi segua possa facilmente guardare il mio codice e capire cosa sta succedendo (non ci riesco sempre). Le interruzioni lo riducono perché introducono strani punti di entrata / uscita. Abusati possono comportarsi in modo molto simile a un'affermazione "goto" fuori di testa.

Assolutamente no ... Sì, l'uso di gotoè negativo perché deteriora la struttura del programma ed è anche molto difficile comprendere il flusso di controllo.

Ma l'uso di dichiarazioni come breake continuesono assolutamente necessarie in questi giorni e non è considerato affatto una cattiva pratica di programmazione.

Inoltre, non è così difficile comprendere il flusso di controllo in uso di breake continue. In costrutti come switchl' breakaffermazione è assolutamente necessario.

L'idea essenziale deriva dalla capacità di analizzare semanticamente il tuo programma. Se si dispone di una singola voce e di una singola uscita, la matematica necessaria per indicare i possibili stati è notevolmente più semplice rispetto alla gestione dei percorsi di biforcazione.

In parte, questa difficoltà si riflette nella capacità di ragionare concettualmente sul tuo codice.

Francamente, il tuo secondo codice non è ovvio. Cosa sta facendo? Continue 'continue' o 'next' il loop? Non ne ho idea. Almeno il tuo primo esempio è chiaro.

Sostituirei il tuo secondo frammento di codice con

while (primary_condition && (loop_count <= 1000 && time_exect <= 3600)) {
    if (this->data != "undefined" && this->skip != true) {
        ..
    }
}

non per alcun motivo di terseness - in realtà penso che sia più facile da leggere e che qualcuno capisca cosa sta succedendo. In generale, le condizioni per i tuoi loop dovrebbero essere contenute esclusivamente in quelle condizioni di loop non disseminate in tutto il corpo. Tuttavia ci sono alcune situazioni in cui breake continuepuò aiutare la leggibilità. breakpiù di quanto continuepotrei aggiungere: D

Non sono d'accordo con il tuo capo. Ci sono posti adeguati per breake continueda usare. In effetti il ​​motivo per cui le esecuzioni e la gestione delle eccezioni sono state introdotte nei moderni linguaggi di programmazione è che non è possibile risolvere ogni problema usando semplicemente structured techniques.

Da un lato , non voglio iniziare una discussione religiosa qui, ma potresti ristrutturare il tuo codice per renderlo ancora più leggibile in questo modo:

while (primary_condition) {
    if (loop_count > 1000) || (time_exect > 3600) {
        break;
    } else if ( ( this->data != "undefined") && ( !this->skip ) ) {
       ... // where the real work of the loop happens
    }
}

In un'altra nota a margine

Personalmente non mi piace l'uso di ( flag == true )in conditionals perché se la variabile è già un valore booleano, stai introducendo un ulteriore confronto che deve verificarsi quando il valore del valore booleano ha la risposta che desideri - a meno che, naturalmente, non sei sicuro che il tuo compilatore lo farà ottimizzare quel confronto extra via.

Sono d'accordo con il tuo capo. Sono cattivi perché producono metodi con elevata complessità ciclomatica. Tali metodi sono difficili da leggere e difficili da testare. Fortunatamente c'è una soluzione semplice. Estrarre il corpo del ciclo in un metodo separato, in cui "continua" diventa "ritorno". "Ritorno" è meglio perché dopo "ritorno" è finita - non ci sono preoccupazioni per lo stato locale.

Per "break" estrai il loop stesso in un metodo separato, sostituendo "break" con "return".

Se i metodi estratti richiedono un gran numero di argomenti, questa è un'indicazione per estrarre una classe - o raccoglierli in un oggetto di contesto.

Penso che sia solo un problema quando nidificato in profondità all'interno di più loop. È difficile sapere in quale loop ti stai interrompendo. Potrebbe essere difficile seguire anche un proseguimento, ma penso che il vero dolore provenga dalle interruzioni - la logica può essere difficile da seguire.

Finché non vengono utilizzati come goto mascherati come nell'esempio seguente:

do
{
      if (foo)
      {
             /*** code ***/
             break;
      }

      if (bar)
      {
             /*** code ***/
             break;
      }
} while (0);

Sto bene con loro. (Esempio visto nel codice di produzione, meh)

Non mi piace nessuno di questi stili. Ecco cosa preferirei:

function verify(object)
{
    if not (object->value < 0) 
       and not(object->value > object->max_value)
       and not(object->name == "") 
       {
         do somethign important
       }
    else return false; //probably not necessary since this function doesn't even seem to be defined to return anything...?
}

Non mi piace davvero usare returnper interrompere una funzione. Sembra un abuso di return.

Anche l'utilizzo breaknon è sempre chiaro da leggere.

Meglio ancora potrebbe essere:

notdone := primarycondition    
while (notDone)
{
    if (loop_count > 1000) or (time_exect > 3600)
    {
       notDone := false; 
    }
    else
    { 
        skipCurrentIteration := (this->data == "undefined") or (this->skip == true) 

        if not skipCurrentIteration
        {
           do something
        } 
        ...
    }
}

meno annidamento e le condizioni complesse vengono trasformate in variabili (in un vero programma dovresti avere nomi migliori, ovviamente ...)

(Tutto il codice sopra è pseudo-codice)

No. È un modo per risolvere un problema e ci sono altri modi per risolverlo.

Molti linguaggi mainstream attuali (Java, .NET (C # + VB), PHP, scrivi il tuo) usano "break" e "continue" per saltare i loop. Entrambe le frasi "goto strutturato (s)".

Senza di loro:

String myKey = "mars";

int i = 0; bool found = false;
while ((i < MyList.Count) && (not found)) {
  found = (MyList[i].key == myKey);
  i++;   
}
if (found)
  ShowMessage("Key is " + i.toString());
else
  ShowMessage("Not found.");

Con loro:

String myKey = "mars";

for (i = 0; i < MyList.Count; i++) {
  if (MyList[i].key == myKey)
    break;
}
ShowMessage("Key is " + i.toString());

Si noti che, il codice "break" e "continue" è più breve e di solito trasforma "mentre" frasi in frasi "for" o "foreach".

Entrambi i casi sono una questione di stile di codifica. Preferisco non usarli , perché lo stile dettagliato mi permette di avere un maggiore controllo del codice.

In realtà, lavoro in alcuni progetti, dove era obbligatorio usare quelle frasi.

Alcuni sviluppatori potrebbero pensare che non siano necessariamente necessari, ma ipotetici, se dovessimo rimuoverli, dobbiamo rimuovere anche "while" e "do while" ("ripeti fino a", ragazzi pascal) ;-)

Conclusione, anche se preferisco non usarle, penso che sia un'opzione, non una cattiva pratica di programmazione.

Non sono contrario continuee breakin linea di principio, ma penso che siano costrutti di livello molto basso che molto spesso possono essere sostituiti da qualcosa di ancora migliore.

Sto usando C # come esempio qui, considera il caso di voler iterare su una raccolta, ma vogliamo solo gli elementi che soddisfano un predicato e non vogliamo fare più di un massimo di 100 iterazioni.

for (var i = 0; i < collection.Count; i++)
{
    if (!Predicate(item)) continue;
    if (i >= 100) break; // at first I used a > here which is a bug. another good thing about the more declarative style!

    DoStuff(item);
}

Questo sembra REASONABLY pulito. Non è molto difficile da capire. Penso che sarebbe molto utile essere più dichiarativi però. Confrontalo con il seguente:

foreach (var item in collection.Where(Predicate).Take(100))
    DoStuff(item);

Forse le chiamate Where and Take non dovrebbero nemmeno essere in questo metodo. Forse questo filtro dovrebbe essere fatto PRIMA che la raccolta sia passata a questo metodo. Ad ogni modo, allontanandoci dalle cose di basso livello e concentrandoci maggiormente sulla reale logica di business, diventa più chiaro ciò a cui siamo REALMENTE interessati. Diventare più facile separare il nostro codice in moduli coerenti che aderiscono maggiormente alle buone pratiche di progettazione e così sopra.

Roba di basso livello esisterà ancora in alcune parti del codice, ma vogliamo nasconderlo il più possibile, perché invece ci vuole energia mentale che potremmo usare per ragionare sui problemi aziendali.

Code Complete ha una bella sezione sull'uso gotoe sui ritorni multipli dalla routine o dal loop.

In generale non è una cattiva pratica. breako continuedire esattamente cosa succede dopo. E sono d'accordo con questo.

Steve McConnell (autore di Code Complete) usa quasi gli stessi esempi per dimostrare i vantaggi dell'utilizzo di varie gotodichiarazioni.

Tuttavia uso eccessivo breako continuepotrebbe portare a software complessi e non mantenibili.