All'interno di un ciclo continuo, devo spostare la condizione di interruzione nel campo condizione, se possibile? [chiuso]

A volte ho bisogno di loop che hanno bisogno di una pausa come questa:

for(int i=0;i<array.length;i++){
    //some other code
    if(condition){
        break;
    }
}

Mi sento a disagio con la scrittura

if(condition){
    break;
}

perché consuma 3 righe di codice. E ho scoperto che il loop può essere riscritto come:

                                   ↓
for(int i=0;i<array.length && !condition;i++){
    //some other code
}

Quindi la mia domanda è: è buona pratica spostare la condizione nel campo condizione per ridurre le linee di codici, se possibile?

Quei due esempi che hai fornito non sono funzionalmente equivalenti. Nell'originale, il test delle condizioni viene eseguito dopo la sezione "qualche altro codice", mentre nella versione modificata viene eseguito per primo, all'inizio del corpo del ciclo.

Il codice non deve mai essere riscritto al solo scopo di ridurre il numero di righe. Ovviamente è un bel bonus quando funziona in questo modo, ma non dovrebbe mai essere fatto a spese della leggibilità o correttezza.

Non compro l'argomento secondo cui "consuma 3 righe di codice" e quindi è un male. Dopotutto, potresti semplicemente scriverlo come:

if (condition) break;

e consuma solo una riga.

Se ifappare a metà del ciclo, ovviamente deve esistere come test separato. Tuttavia, se questo test appare alla fine del blocco, è stato creato un ciclo che ha un test continuo su entrambe le estremità del ciclo, aggiungendo eventualmente alla complessità del codice. Tenere presente, tuttavia, che a volte il if (condition)test può avere senso solo dopo l'esecuzione del blocco.

Ma supponendo che non sia così, adottando l'altro approccio:

for(int i=0;i<array.length && !condition;i++){
    //some other code
}

le condizioni di uscita sono mantenute insieme, il che può semplificare le cose (specialmente se " qualche altro codice " è lungo).

Naturalmente non c'è una risposta giusta qui. Quindi sii consapevole dei modi di dire della lingua, quali sono le convenzioni di codifica della tua squadra, ecc. Ma a conti fatti, adotterò il singolo approccio di test quando ha senso funzionale farlo.

Questo tipo di domanda ha suscitato il dibattito quasi quanto la programmazione. Per lanciare il mio cappello sul ring, sceglierei la versione con la breakcondizione ed ecco perché (per questo caso specifico ):

Il forciclo è proprio lì per specificare i valori iteranti nel ciclo. Codificare la condizione di rottura all'interno che confonde la logica IMO.

La presenza di un elemento separato breakchiarisce chiaramente che durante l'elaborazione normale, i valori sono quelli specificati nel forciclo e l'elaborazione deve continuare tranne nel caso in cui si verifichi la condizione.

Come un po 'di background, ho iniziato a scrivere codice a break, quindi ho messo le condizioni in forloop per anni (sotto la direzione di un programmatore eccezionale) e poi sono tornato allo breakstile perché mi sentivo molto più pulito (ed era lo stile prevalente in i vari tomi di codice che stavo consumando).

È un'altra di quelle guerre sante alla fine della giornata - alcuni dicono che non dovresti mai uscire artificialmente da un ciclo, altrimenti non è un vero ciclo. Fai ciò che ritieni sia leggibile (sia per te che per gli altri). Se ridurre le sequenze di tasti è davvero la tua passione, vai a golf nel fine settimana - birra opzionale.

fori loop sono per l'iterazione su qualcosa di ¹ - non sono solo lol-Let's-pull-some-random-stuff-from-the-body-and-put-them-in-the-loop-header - le tre espressioni hanno molto significati specifici:

• Il primo è per inizializzare l' iteratore . Può essere un indice, un puntatore, un oggetto di iterazione o altro, purché sia ​​utilizzato per l' iterazione .
• Il secondo è per verificare se siamo arrivati ​​alla fine.
• Il terzo è per far avanzare l'iteratore.

L'idea è quella di separare la gestione dell'iterazione ( come iterare) dalla logica all'interno del ciclo ( cosa fare in ogni iterazione). Molte lingue di solito hanno un ciclo per ogni che ti allevia dai dettagli dell'iterazione, ma anche se la tua lingua non ha quel costrutto o se non può essere usata nel tuo scenario, dovresti comunque limitare l'intestazione del ciclo alla gestione dell'iterazione.

Quindi, devi chiederti: è la tua condizione sulla gestione dell'iterazione o sulla logica all'interno del ciclo? È probabile che si tratti della logica all'interno del loop, quindi dovrebbe essere verificata all'interno del loop piuttosto che nell'intestazione.

¹ A differenza di altri loop, che "aspettano" che accada qualcosa. A for/ foreachloop dovrebbe avere il concetto di un "elenco" di elementi su cui scorrere - anche se tale elenco è pigro, infinito o astratto.

Consiglio di utilizzare la versione con if (condition). È più leggibile e più facile da eseguire il debug. Scrivere 3 righe di codice in più non ti romperà le dita, ma renderà più facile per la prossima persona capire il tuo codice.

Se stai ripetendo una raccolta in cui alcuni elementi devono essere ignorati, ti consiglio una nuova opzione:

• Filtra la tua raccolta prima di iterare

Sia Java che C # lo rendono relativamente banale. Non sarei sorpreso se C ++ avesse un modo per creare un iteratore di fantasia per saltare alcuni elementi che non si applicano. Ma questa è davvero un'opzione solo se la tua lingua preferita la supporta e il motivo che stai usando breakè perché ci sono condizioni sul fatto che tu elabori un elemento o meno.

Altrimenti c'è un ottimo motivo per rendere la tua condizione parte del ciclo for - supponendo che la sua valutazione iniziale sia corretta.

• È più facile vedere quando un ciclo termina presto

Ho lavorato sul codice in cui il tuo ciclo for prende alcune centinaia di righe con diversi condizionali e qualche matematica complessa in corso lì. I problemi che incontri con questo sono:

• break i comandi nascosti nella logica sono difficili da trovare e talvolta sorprendenti
• Il debug richiede di passare attraverso ogni iterazione del ciclo per capire veramente cosa sta succedendo
• Gran parte del codice non dispone di refactoring facilmente reversibili o unit test per aiutare con l'equivalenza funzionale dopo una riscrittura

In tale situazione, raccomando le seguenti linee guida in ordine di preferenza:

• Filtra la raccolta per eliminare la necessità di un breakse possibile
• Rendi la parte condizionale delle condizioni del ciclo for
• Posizionare i condizionali con il breaknella parte superiore del loop, se possibile
• Aggiungi un commento su più righe per attirare l'attenzione sull'interruzione e perché è lì

Queste linee guida sono sempre soggette alla correttezza del codice. Scegli l'opzione che può rappresentare al meglio l'intento e migliorare la chiarezza del codice.

Consiglio vivamente di adottare l'approccio di minima sorpresa a meno che tu non ottenga un beneficio significativo facendo diversamente.

Le persone non leggono tutte le lettere quando leggono una parola e non leggono tutte le parole quando leggono un libro - se sono abili nella lettura, guardano i contorni delle parole e delle frasi e lasciano che il cervello si riempia del resto .

Quindi è probabile che lo sviluppatore occasionale supponga che questo sia solo uno standard per il loop e nemmeno lo guardi:

for(int i=0;i<array.length&&!condition;i++)

Se vuoi usare quello stile a prescindere, ti consiglio di cambiare le parti for(int i=0;i<e ;i++)dire al cervello del lettore che questo è uno standard per il loop.

Un altro motivo per andare con if- breakè che non si può sempre utilizzare il tuo approccio con la for-condition. Devi usare if- breakquando la condizione di interruzione è troppo complessa per nascondersi all'interno di forun'istruzione o si basa su variabili accessibili solo all'interno del forciclo.

for(int i=0;i<array.length&&!((someWidth.X==17 && y < someWidth.x/2) || (y == someWidth.x/2 && someWidth.x == 18);i++)

Quindi, se decidi di andare con if- break, sei coperto. Ma se si decide di andare con forCircostanze, è necessario utilizzare un mix di if- breake forCircostanze. Per essere coerenti, dovrai spostare le condizioni avanti e indietro tra le condizioni fore il if- breakogni volta che le condizioni cambiano.

La tua trasformazione presuppone che qualsiasi cosa conditionvenga valutata truementre entri nel ciclo. Non possiamo commentare la correttezza di ciò in questo caso perché non è definito.

Avendo successo nel "ridurre le righe di codice" qui, puoi continuare a guardare

for(int i=0;i<array.length;i++){
    // some other code
    if(condition){
        break;
    }
    // further code
}

e applicare la stessa trasformazione, arrivando a

for(int i=0;i<array.length && !condition;i++){
    // some other code
    // further code
}

Che è una trasformazione non valida, come ora fai incondizionatamente further codedove prima non l'hai fatto.

Uno schema di trasformazione molto più sicuro è quello di estrarre some other codee valutare conditionuna funzione separata

bool evaluate_condition(int i) // This is an horrible name, but I have no context to improve it
{
     // some other code
     return condition;
}

for(int i=0;i<array.length && !evaluate_condition(i);i++){
    // further code
}

TL; DR Fai ciò che legge meglio nella tua particolare circostanza

Facciamo questo esempio:

for ( int i = 1; i < array.length; i++ ) 
{
    if(something) break;
    // perform operations
}

In questo caso non vogliamo che nessuno dei codici nel ciclo for somethingvenga eseguito se è vero, quindi somethingè ragionevole spostare il test nel campo condizione.

for ( int i = 1; i < array.length && !something; i++ )

Poi di nuovo, a seconda se somethingpuò essere impostato trueprima del loop, ma non al suo interno, questo potrebbe offrire maggiore chiarezza:

if(!something)
{
    for ( int i = 1; i < array.length; i++ )
    {...}
}

Ora immagina questo:

for ( int i = 1; i < array.length; i++ ) 
{
    // perform operations
    if(something) break;
    // perform more operations
}

Stiamo inviando un messaggio molto chiaro lì. Se somethingdiventa vero durante l'elaborazione dell'array, abbandonare l'intera operazione a questo punto. Per spostare il segno di spunta nel campo condizione è necessario:

for ( int i = 1; i < array.length && !something; i++ ) 
{
    // perform operations
    if(!something)
    {
        // perform more operations
    }
}

Probabilmente, il "messaggio" è diventato confuso e stiamo verificando la condizione di errore in due punti: cosa succede se la condizione di errore cambia e dimentichiamo uno di quei luoghi?

Naturalmente ci sono molte altre forme diverse per un ciclo e una condizione, tutte con le loro sfumature.

Scrivi il codice in modo che legga bene (questo è ovviamente in qualche modo soggettivo) e conciso. Al di fuori di una serie draconiana di linee guida per la codifica, tutte le "regole" hanno eccezioni. Scrivi ciò che ritieni esprime meglio il processo decisionale e minimizza le possibilità di errori futuri.

Mentre può essere attraente perché vedi tutte le condizioni nell'intestazione del loop e breakpuò essere confuso all'interno di blocchi di grandi dimensioni, un forloop è un modello in cui la maggior parte dei programmatori si aspetta che eseguano il loop su un certo intervallo.

Soprattutto da quando lo fai, l'aggiunta di una condizione di interruzione aggiuntiva può causare confusione ed è più difficile vedere se è funzionalmente equivalente.

Spesso una buona alternativa è usare un ciclo whileo do {} whileche controlla entrambe le condizioni, supponendo che l'array abbia almeno un elemento.

int i=0
do {
    // some other code
    i++; 
} while(i < array.length && condition);

Usando un ciclo che controlla solo una condizione e non esegue il codice dall'intestazione del ciclo, rendi molto chiaro quando la condizione è selezionata e qual è la condizione effettiva e qual è il codice con effetti collaterali.

Questo è negativo, poiché il codice deve essere letto dagli umani - i forloop non idiomatici sono spesso confusi da leggere, il che significa che è più probabile che i bug si nascondano qui, ma il codice originale potrebbe essere stato possibile migliorare mantenendo entrambi breve e leggibile.

Se quello che vuoi è trovare un valore in un array (l'esempio di codice fornito è in qualche modo generico, ma potrebbe anche essere questo modello), puoi semplicemente provare esplicitamente a usare una funzione fornita da un linguaggio di programmazione appositamente a tale scopo. Ad esempio (pseudo-codice, poiché non è stato specificato un linguaggio di programmazione, le soluzioni variano a seconda di un determinato linguaggio).

array.find(item -> item.valid)

Ciò dovrebbe abbreviare sensibilmente la soluzione, semplificandola nel momento in cui il codice dice specificamente ciò di cui hai bisogno.

Poche ragioni secondo me dicono che non dovresti.

1. Ciò riduce la leggibilità.
   
2. L'output potrebbe non essere lo stesso. Tuttavia, può essere eseguito con un do...whileciclo (non while) poiché la condizione viene verificata dopo l'esecuzione di un codice.
   

Ma soprattutto, considera questo,

for(int i=0;i<array.length;i++){

    // Some other code
    if(condition1){
        break;
    }

    // Some more code
    if(condition1){
        break;
    }

    // Some even more code
}

Ora, puoi davvero raggiungerlo aggiungendo queste condizioni in quella forcondizione?

Penso che rimuovere il breakpuò essere una buona idea, ma non per salvare righe di codice.

Il vantaggio di scriverlo senza breakè che la post-condizione del loop è ovvia ed esplicita. Quando finisci il ciclo ed esegui la riga successiva del programma, la condizione del tuo ciclo i < array.length && !conditiondeve essere stata falsa. Pertanto, o iera maggiore o uguale alla lunghezza dell'array o conditionè vero.

Nella versione con break, c'è un gotcha nascosto. La condizione del ciclo dice che il ciclo termina quando hai eseguito qualche altro codice per ciascun indice di array valido, ma esiste in realtà breakun'istruzione che potrebbe terminare il ciclo prima di quello, e non lo vedrai se non riesci a rivedere il codice del ciclo molto attentamente. E gli analizzatori statici automatizzati, incluso l'ottimizzazione dei compilatori, potrebbero avere difficoltà a dedurre anche quali sono le post-condizioni del loop.

Questa era la ragione originale per cui Edgar Dijkstra scrisse "Goto Considered Harmful". Non era una questione di stile: uscire da un ciclo rende difficile formalmente ragionare sullo stato del programma. Ho scritto molte break;dichiarazioni nella mia vita e, una volta da adulto, ho anche scritto un goto(per uscire da più livelli di un ciclo interno critico per le prestazioni e poi continuare con un altro ramo dell'albero di ricerca). Tuttavia, sono molto più propenso a scrivere returnun'istruzione condizionale da un ciclo (che non esegue mai il codice dopo il ciclo e quindi non può confondere le sue post-condizioni) rispetto a a break.

poscritto

In effetti, il refactoring del codice per fornire lo stesso comportamento potrebbe effettivamente richiedere più righe di codice. Il tuo refactoring potrebbe essere valido in particolare per qualche altro codice o se possiamo provare che conditioninizierà falso. Ma il tuo esempio è equivalente nel caso generale a:

if ( array.length > 0 ) {
  // Some other code.
}
for ( int i = 1; i < array.length && !condition; i++ ) {
  // Some other code.
}

Se qualche altro codice non è un one-liner, potresti spostarlo in una funzione in modo da non ripetere te stesso, e quindi hai quasi rifattorizzato il tuo loop in una funzione ricorsiva della coda.

Riconosco che questo non era il punto principale della tua domanda, e lo stavi mantenendo semplice.

Sì, ma la tua sintassi è non convenzionale e quindi male (tm)

Spero che la tua lingua supporti qualcosa del genere

while(condition) //condition being a condition which if true you want to continue looping
{
    do thing; //your conditionally executed code goes here
    i++; //you can use a counter if you want to reference array items in order of index
}

Se sei preoccupato che forun'affermazione troppo complessa sia difficile da leggere, questa è sicuramente una preoccupazione valida. Anche lo spreco di spazio verticale è un problema (sebbene meno critico).

(Personalmente non mi piace la regola secondo cui le ifistruzioni devono sempre avere parentesi graffe, che è in gran parte la causa dello spazio verticale sprecato qui. Nota che il problema sta sprecando spazio verticale. L' uso dello spazio verticale con linee significative non dovrebbe essere un problema.)

Un'opzione è dividerlo su più righe. Questo è sicuramente ciò che dovresti fare se stai usando foristruzioni davvero complesse , con più variabili e condizioni. (Questo è per me un migliore utilizzo dello spazio verticale, dando quante più righe possibile qualcosa di significativo.)

for (
   int i = 0, j = 0;
   i < array.length && !condition;
   i++, j++
) {
   // stuff
}

Un approccio migliore potrebbe essere quello di provare a utilizzare una forma più dichiarativa e meno imperativa. Questo varierà a seconda della lingua, oppure potresti dover scrivere le tue funzioni per abilitare questo genere di cose. Dipende anche da cosa sia conditioneffettivamente. Presumibilmente deve essere in grado di cambiare in qualche modo, a seconda di ciò che è nella matrice.

array
.takeWhile(condition)  // condition can be item => bool or (item, index) => bool
.forEach(doSomething); // doSomething can be item => void or (item, index) => void

Una cosa che è stata dimenticata: quando mi interrompo da un ciclo (non faccio tutte le possibili iterazioni, non importa quanto implementato), di solito è il caso che non solo voglio uscire dal ciclo, voglio anche sapere perché è successo . Ad esempio, se cerco un elemento X, non solo mi interrompo dal ciclo, voglio anche sapere che X è stato trovato e dove si trova.

In quella situazione, avere una condizione al di fuori del ciclo è abbastanza naturale. Quindi inizio con

bool found = false;
size_t foundIndex;

e nel ciclo scriverò

if (condition) {
    found = true;
    foundIndex = i;
    break;
}

con il ciclo for

for (i = 0; i < something && ! found; ++i)

Ora controllare la condizione nel loop è abbastanza naturale. La presenza o meno di un'istruzione "break" dipende dall'eventuale ulteriore elaborazione nel loop che si desidera evitare. Se è necessaria una certa elaborazione e altre no, potresti avere qualcosa di simile

if (! found) { ... }

da qualche parte nel tuo ciclo.