Ho sempre sentito parlare di una singola funzione di punto di uscita come un cattivo modo di codificare perché perdi leggibilità ed efficienza. Non ho mai sentito nessuno discutere dall'altra parte.
Pensavo avesse qualcosa a che fare con CS, ma questa domanda è stata risolta in cstheory stackexchange.
Risposte:
Esistono diverse scuole di pensiero e dipende in gran parte dalle preferenze personali.
Uno è che crea meno confusione se c'è un solo punto di uscita: hai un unico percorso attraverso il metodo e sai dove cercare l'uscita. Sul lato negativo, se usi il rientro per rappresentare l'annidamento, il tuo codice finisce per rientrare in modo massiccio a destra e diventa molto difficile seguire tutti gli ambiti annidati.
Un altro è che puoi controllare le precondizioni ed uscire in anticipo all'inizio di un metodo, in modo da sapere nel corpo del metodo che determinate condizioni sono vere, senza che l'intero corpo del metodo sia rientrato di 5 miglia a destra. Questo di solito riduce al minimo il numero di ambiti di cui ti devi preoccupare, il che rende il codice molto più facile da seguire.
Un terzo è che puoi uscire ovunque tu voglia. Un tempo questo creava più confusione, ma ora che abbiamo editor e compilatori che colorano la sintassi che rilevano il codice non raggiungibile, è molto più facile da gestire.
Sono esattamente nel campo centrale. L'imposizione di un singolo punto di uscita è una restrizione inutile o addirittura controproducente IMHO, mentre uscire a caso su un metodo a volte può portare a una logica disordinata e difficile da seguire, dove diventa difficile vedere se un dato bit di codice sarà o non sarà eseguito. Ma il "gating" del metodo consente di semplificare notevolmente il corpo del metodo.
singe exitparadigma a forza di go toaffermazioni. Inoltre, si ha la possibilità di eseguire un po 'di postelaborazione sotto l' Erroretichetta locale della funzione , cosa impossibile con più returns.
La mia raccomandazione generale è che le istruzioni di ritorno dovrebbero, quando possibile, essere posizionate prima del primo codice che ha effetti collaterali o dopo l'ultimo codice che ha effetti collaterali. Considererei qualcosa di simile:
if (! argomento) // Controlla se non è nullo
return ERR_NULL_ARGUMENT;
... processare un argomento non nullo
se (ok)
return 0;
altro
return ERR_NOT_OK;
più chiaro di:
int valore_ritorno;
if (argomento) // Non nullo
{
.. processare un argomento non nullo
.. impostare il risultato in modo appropriato
}
altro
risultato = ERR_NULL_ARGUMENT;
risultato di ritorno;
Se una certa condizione dovrebbe impedire a una funzione di fare qualcosa, preferisco uscire anticipatamente dalla funzione in un punto sopra il punto in cui la funzione farebbe qualsiasi cosa. Una volta che la funzione ha intrapreso azioni con effetti collaterali, però, preferisco tornare dal basso, per chiarire che tutti gli effetti collaterali devono essere affrontati.
okvariabile, mi sembra l'approccio a ritorno singolo. Inoltre, il blocco if-else può essere semplicemente riscritto in:return ok ? 0 : ERR_NOT_OK;
returnall'inizio prima di tutto il codice che fa tutto. Per quanto riguarda l'utilizzo ?:dell'operatore, scriverlo su righe separate rende più facile per molti IDE allegare un punto di interruzione di debug allo scenario non ok. A proposito, la vera chiave del "singolo punto di uscita" sta nel capire che ciò che conta è che per ogni chiamata particolare a una funzione normale, il punto di uscita è il punto immediatamente dopo la chiamata . I programmatori oggigiorno lo danno per scontato, ma le cose non sono sempre state così. In alcuni rari casi il codice potrebbe dover cavarsela senza spazio nello stack, portando a funzioni ...
Un unico punto di ingresso e di uscita era il concetto originale di programmazione strutturata vs Spaghetti Coding passo dopo passo. C'è la convinzione che più funzioni di punto di uscita richiedano più codice poiché è necessario pulire adeguatamente gli spazi di memoria allocati per le variabili. Si consideri uno scenario in cui la funzione alloca variabili (risorse) e uscire dalla funzione in anticipo e senza un'adeguata pulizia comporterebbe perdite di risorse. Inoltre, la creazione di clean-up prima di ogni uscita creerebbe molto codice ridondante.
Con quasi tutto, si riduce alle esigenze del deliverable. Nei "vecchi tempi", il codice spaghetti con più punti di ritorno invitava a perdite di memoria, poiché i programmatori che preferivano quel metodo in genere non pulivano bene. Ci sono stati anche problemi con alcuni compilatori che "perdevano" il riferimento alla variabile return quando lo stack veniva estratto durante il ritorno, nel caso di ritorno da uno scope annidato. Il problema più generale era quello del codice rientrante, che tenta di fare in modo che lo stato di chiamata di una funzione sia esattamente lo stesso del suo stato di ritorno. I mutatori di oop hanno violato questo e il concetto è stato accantonato.
Ci sono risultati finali, in particolare i kernel, che richiedono la velocità fornita da più punti di uscita. Questi ambienti normalmente hanno una propria memoria e gestione dei processi, quindi il rischio di una perdita è ridotto al minimo.
Personalmente, mi piace avere un unico punto di uscita, dal momento che lo uso spesso per inserire un punto di interruzione sull'istruzione return ed eseguire un'ispezione del codice su come il codice ha determinato quella soluzione. Potrei semplicemente andare all'ingresso e attraversarlo, cosa che faccio con soluzioni ampiamente nidificate e ricorsive. In qualità di revisore del codice, più resi in una funzione richiedono un'analisi molto più approfondita, quindi se lo fai per accelerare l'implementazione, stai derubando Peter per salvare Paul. Sarà richiesto più tempo nelle revisioni del codice, invalidando la presunzione di un'implementazione efficiente.
- 2 centesimi
Si prega di consultare questo documento per maggiori dettagli: NISTIR 5459
multiple returns in a function requires a much deeper analysissolo se la funzione è già enorme (> 1 schermata), altrimenti facilita l'analisi
A mio avviso, il consiglio di uscire da una funzione (o da un'altra struttura di controllo) in un solo punto è spesso ipervenduto. In genere vengono fornite due ragioni per uscire in un solo punto:
La seconda ragione è sottile e ha qualche merito, soprattutto se la funzione restituisce una grande struttura di dati. Tuttavia, non me ne preoccuperei troppo, tranne ...
Se sei uno studente, vuoi ottenere il massimo dei voti nella tua classe. Fai quello che preferisce l'istruttore. Probabilmente ha una buona ragione dal suo punto di vista; quindi, per lo meno, imparerai la sua prospettiva. Questo ha valore in sé.
In bocca al lupo.
Ero un sostenitore dello stile a uscita singola. Il mio ragionamento proveniva principalmente dal dolore ...
L'uscita singola è più facile da eseguire il debug.
Date le tecniche e gli strumenti che abbiamo oggi, questa è una posizione molto meno ragionevole da prendere in quanto i test unitari e la registrazione possono rendere superflua l'uscita singola. Detto questo, quando è necessario osservare l'esecuzione del codice in un debugger, è stato molto più difficile capire e lavorare con codice contenente più punti di uscita.
Ciò è diventato particolarmente vero quando era necessario intercettare assegnazioni per esaminare lo stato (sostituito con espressioni di controllo nei debugger moderni). Era anche troppo facile alterare il flusso di controllo in modi che nascondevano il problema o interrompevano del tutto l'esecuzione.
I metodi a uscita singola erano più facili da eseguire nel debugger e più facili da separare senza rompere la logica.
La risposta dipende molto dal contesto. Se stai creando una GUI e hai una funzione che inizializza le API e apre le finestre all'inizio del tuo main, sarà pieno di chiamate che potrebbero generare errori, ognuno dei quali causerebbe la chiusura dell'istanza del programma. Se hai usato istruzioni IF annidate e indentavi, il tuo codice potrebbe rapidamente diventare molto inclinato a destra. Restituire un errore in ogni fase potrebbe essere migliore e in realtà più leggibile pur essendo altrettanto facile da eseguire il debug con alcuni flag nel codice.
Se, tuttavia, stai testando condizioni diverse e restituisci valori diversi a seconda dei risultati nel tuo metodo, potrebbe essere una pratica molto migliore avere un unico punto di uscita. Lavoravo sugli script di elaborazione delle immagini in MATLAB che potevano diventare molto grandi. Più punti di uscita potrebbero rendere il codice estremamente difficile da seguire. Le dichiarazioni di switch erano molto più appropriate.
La cosa migliore da fare sarebbe imparare mentre procedi. Se stai scrivendo codice per qualcosa, prova a trovare il codice di altre persone e vedi come lo implementano. Decidi quali bit ti piacciono e quali no.
Se ritieni di aver bisogno di più punti di uscita in una funzione, la funzione è troppo grande e sta facendo troppo.
Consiglierei di leggere il capitolo sulle funzioni nel libro di Robert C. Martin, Clean Code.
In sostanza, dovresti provare a scrivere funzioni con 4 righe di codice o meno.
Alcune note dal blog di Mike Long :