Le istruzioni condizionali non banali devono essere spostate nella sezione di inizializzazione dei loop?

Ho avuto questa idea da questa domanda su stackoverflow.com

Il seguente modello è comune:

final x = 10;//whatever constant value
for(int i = 0; i < Math.floor(Math.sqrt(x)) + 1; i++) {
  //...do something
}

Il punto che sto cercando di fare è che l'affermazione condizionale è qualcosa di complicato e non cambia.

È meglio dichiararlo nella sezione di inizializzazione del loop, come tale?

final x = 10;//whatever constant value
for(int i = 0, j = Math.floor(Math.sqrt(x)) + 1; i < j; i++) {
  //...do something
}

È più chiaro?

E se l'espressione condizionale è semplice come

final x = 10;//whatever constant value
for(int i = 0, j = n*n; i > j; j++) {
  //...do something
}

Quello che farei è qualcosa del genere:

void doSomeThings() {
    final x = 10;//whatever constant value
    final limit = Math.floor(Math.sqrt(x)) + 1;
    for(int i = 0; i < limit; i++) {
         //...do something
    }
}

Onestamente, l'unica buona ragione per stipare l'inizializzazione j(ora limit) nell'intestazione del loop è di mantenerlo correttamente. Tutto ciò che serve per fare in modo che un non-problema sia un ambito di applicazione stretto e piacevole.

Posso apprezzare il desiderio di essere veloce ma non sacrificare la leggibilità senza una vera ragione.

Certo, il compilatore può ottimizzare, l'inizializzazione di più var può essere legale, ma i loop sono abbastanza difficili da eseguire il debug così com'è. Per favore sii gentile con gli umani. Se questo davvero ci rallenta, è bello capirlo abbastanza per risolverlo.

Un buon compilatore genererà lo stesso codice in entrambi i modi, quindi se stai andando per le prestazioni, apporta una modifica solo se si trova in un ciclo critico e lo hai effettivamente profilato e hai trovato che fa la differenza. Anche se il compilatore non è in grado di ottimizzarlo, come la gente ha sottolineato nei commenti sul caso con chiamate di funzione, nella stragrande maggioranza delle situazioni, la differenza di prestazioni sarà troppo piccola per valere la pena di essere considerata da un programmatore.

Tuttavia...

Non dobbiamo dimenticare che il codice è principalmente un mezzo di comunicazione tra umani ed entrambe le opzioni non comunicano molto bene con gli altri umani. Il primo dà l'impressione che l'espressione debba essere calcolata su ogni iterazione, e il secondo nella sezione di inizializzazione implica che verrà aggiornato da qualche parte all'interno del ciclo, dove è veramente costante.

Preferirei davvero che fosse estratto sopra il ciclo e fatto finalper renderlo immediatamente e abbondantemente chiaro a chiunque leggesse il codice. Questo non è l'ideale neanche perché aumenta l'ambito della variabile, ma la tua funzione che racchiude non dovrebbe contenere molto più di quel ciclo comunque.

Come ha affermato @Karl Bielefeldt nella sua risposta, questo di solito non è un problema.

Tuttavia, un tempo era un problema comune in C e C ++, e un trucco si avvicinò al problema senza ridurre la leggibilità del codice - iterare all'indietro, fino a0 .

final x = 10;//whatever constant value
for(int i = Math.floor(Math.sqrt(x)); i >= 0; i--) {
  //...do something
}

Ora il condizionale in ogni iterazione è proprio quello >= 0che ogni compilatore compilerà in 1 o 2 istruzioni di assemblaggio. Ogni CPU prodotta negli ultimi decenni dovrebbe avere controlli di base come questi; facendo un rapido controllo sulla mia macchina x64 vedo che questo si trasforma in prevedibilmente in cmpl $0x0, -0x14(%rbp)(valore di confronto lungo int 0 rispetto al registro rbp compensato -14) e jl 0x100000f59(passa all'istruzione seguendo il ciclo se il confronto precedente era vero per “2nd-arg <1st-arg ”) .

Si noti che ho rimosso il + 1da Math.floor(Math.sqrt(x)) + 1; affinché la matematica si risolva, il valore iniziale dovrebbe essere int i = «iterationCount» - 1. Vale anche la pena notare che il tuo iteratore deve essere firmato; unsigned intnon funzionerà e probabilmente compilerà un avviso.

Dopo aver programmato in linguaggi basati su C per circa 20 anni, ora scrivo solo cicli di iterazione con indice inverso a meno che non ci sia un motivo specifico per iterare con indice in avanti. Oltre ai controlli più semplici nei condizionali, l'iterazione inversa spesso fa anche da contraltare a quelle che altrimenti sarebbero fastidiose mutazioni dell'array durante l'iterazione.

Diventa interessante quando Math.sqrt (x) viene sostituito da Mymodule.SomeNonPureMethodWithSideEffects (x).

Fondamentalmente il mio modus operandi è: se si prevede che qualcosa dia sempre lo stesso valore, valutarlo solo una volta. Ad esempio List.Count, se si prevede che l'elenco non cambi durante il funzionamento del ciclo, ottenere il conteggio esterno al ciclo in un'altra variabile.

Alcuni di questi "conteggi" possono essere sorprendentemente costosi soprattutto quando si ha a che fare con database. Anche se stai lavorando su un set di dati che non dovrebbe cambiare durante l'iterazione dell'elenco.

A mio avviso, questo è altamente specifico della lingua. Ad esempio, se utilizzassi C ++ 11, sospetterei che se il controllo delle condizioni fosse una constexprfunzione, il compilatore sarebbe molto probabilmente in grado di ottimizzare le esecuzioni multiple poiché sa che produrrà lo stesso valore ogni volta.

Tuttavia, se la chiamata di funzione è una funzione di libreria che non è constexpril compilatore, la eseguirà quasi sicuramente su ogni iterazione in quanto non può dedurla (a meno che non sia in linea e quindi possa essere dedotta come pura).

So meno di Java, ma dato che è compilato JIT immagino che il compilatore abbia abbastanza informazioni in fase di esecuzione per probabilmente inline e ottimizzare la condizione. Ma questo farebbe affidamento su una buona progettazione del compilatore e il compilatore che ha deciso che questo ciclo rappresentava una priorità di ottimizzazione che possiamo solo immaginare.

Personalmente ritengo che sia leggermente più elegante mettere la condizione all'interno del ciclo for se puoi, ma se è complessa la scriverò in una constexpro inlinefunzione, o i tuoi linguaggi equivalgono a suggerire che la funzione è pura e ottimizzabile. Ciò rende evidente l'intento e mantiene lo stile idiomatico del loop senza creare una linea enorme illeggibile. Dà anche un nome alla verifica della condizione se è la sua stessa funzione in modo che i lettori possano immediatamente vedere logicamente a cosa serve la verifica senza leggerla se complessa.