È un principio di stile di codifica, ad esempio il principio dell'uscita singola
Alla fine degli anni '60, le persone che ancora protestano per un'uscita singola o per un'uscita multipla sono ancora bloccate. All'epoca, una simile discussione era importante poiché eravamo agli inizi del programmatore strutturato, e c'era un campo abbastanza numeroso che proclamava che i risultati alla base del teorema del programma strutturato Bohm-Jacopini non erano universalmente applicabili a tutti i costrutti di programmazione.
È qualcosa che avrebbe dovuto essere risolto molto tempo fa. Bene, è stato risolto (quasi 4 decenni per essere precisi, sia nel mondo accademico che nel settore), ma le persone (coloro che sono assolutamente pro o contro) non hanno prestato attenzione.
Per quanto riguarda il resto delle mie risposte, è tutto relativo (cosa non è nel software?):
Sì. Il più delle volte per il caso generale, con avvertenze specifiche per casi limite e costrutti di programmazione specifici del linguaggio.
Sempre o solo qualche volta?
La maggior parte delle volte.
Quanta differenza fa davvero?
Dipende.
Codice leggibile vs codice illeggibile. Una maggiore complessità (che dovremmo sapere ora aumenta la probabilità di introdurre errori) rispetto a una complessità più semplice (ed ergo, una minore probabilità di errori.) Lingue i cui compilatori non aggiungono un ritorno implicito (diciamo, Pascal, Java o C #) e quelli che impostazione predefinita su int (C e C ++).
Alla fine, è un'abilità affinata con l'uomo / ore dietro una tastiera. A volte, è ok avere più dichiarazioni di ritorno, come qui (in alcuni pseudocodici di Pascal):
function foo() : someType
begin
if( test1 == true )
then
return x;
end
doSomethignElseThatShouldnHappenIfTest1IsTrue();
return somethingElse();
end;
L'intento è chiaro e l'algoritmo è abbastanza piccolo e abbastanza semplice da non giustificare la creazione di una variabile "flag" che contiene l'eventuale valore di ritorno utilizzato in un singolo punto di ritorno. L'algoritmo potrebbe essere in errore, ma la sua struttura è abbastanza semplice da rendere (molto probabilmente) trascurabile lo sforzo di rilevare un errore.
A volte non lo è (qui usando uno pseudocodice di tipo C):
switch(someVal)
{
case v1 : return x1;
case v2 : return x2:
case v3 : doSomething(); // fall-through
case v4: // fall-through
case v5: // fall-through
case v6: return someXthingie;
...
...
default:
doSomething(); // no return statement yet
}
Qui, l'algoritmo non ha una struttura semplice e l'istruzione switch (una di tipo C) consente passaggi di fall-through che possono o meno essere eseguiti intenzionalmente come parte dell'algoritmo.
Forse l'algoritmo è corretto, ma scritto male.
O forse, da forze esterne al di là delle capacità del programmatore, questa è la rappresentazione effettiva (e corretta) di un algoritmo legittimamente necessario.
Forse è sbagliato.
Per scoprire la verità di tutto ciò è necessario uno sforzo molto maggiore rispetto all'esempio precedente. E qui sta qualcosa in cui credo fermamente (badate che non ho studi formali per sostenere questo):
Supponendo che uno snippet di codice sia corretto:
Le dichiarazioni di ritorno multiple aumentano la leggibilità e la semplicità di un tale frammento di codice, se il frammento rappresenta un algoritmo semplice con una struttura di flusso intrinsecamente semplice. Per semplice, non intendo piccolo, ma intendo intrinsecamente comprensibile o prova di sé , ciò che non richiede uno sforzo di lettura sproporzionato (né indurre le persone a vomitare, maledire la madre di qualcuno o ingoiare un proiettile quando devono leggerlo. )
Una singola dichiarazione di ritorno aumenta la leggibilità e la semplicità di tale codice se il valore di ritorno viene calcolato durante l'esecuzione dell'algoritmo o se i passaggi dell'algoritmo responsabile del calcolo possono essere raggruppati in un'unica posizione all'interno della struttura dell'algoritmo .
Una singola dichiarazione di ritorno riduce la leggibilità e la semplicità di tale codice se richiede assegnazioni a una o più variabili flag, con le posizioni di tali assegnazioni non posizionate uniformemente in tutto l'algoritmo.
Le dichiarazioni di ritorno multiple riducono la leggibilità e la semplicità di tale codice se le dichiarazioni di ritorno non sono distribuite uniformemente in tutto l'algoritmo e se delimitano blocchi di codice reciprocamente esclusivi che non sono uniformi nelle dimensioni o nella struttura tra di loro.
Ciò è strettamente correlato alla complessità di uno snippet di codice in questione. E questo a sua volta è correlato a misure di complessità ciclomatica e di stabilità. Da ciò, si potrebbe osservare quanto segue:
Maggiore è la dimensione di una subroutine o di una funzione, più ampia e complessa è la struttura del flusso di controllo interno e maggiore è la probabilità che si debba affrontare la questione se utilizzare dichiarazioni di ritorno multiple o singole.
La conclusione è: mantieni piccole le tue funzioni facendo una cosa e solo una cosa (e facendola bene). Se esibiscono metriche nominalmente piccole di complessità ciclomatica e di stabilità, non solo saranno probabilmente corrette e saranno implementate attività comprensibili, ma anche le loro strutture interne saranno relativamente evidenti.
Quindi, e solo allora puoi abbastanza facilmente e senza perdere molto sonno, puoi decidere se utilizzare un singolo ritorno e più ritorni senza correre molti rischi di introdurre errori con entrambe le scelte.
Si potrebbe anche considerare tutto ciò e suggerire che quando le persone lottano con il problema dei rendimenti singoli o dei rendimenti multipli, è perché - per inesperienza, stupidità o mancanza di etica del lavoro - non scrivono codice pulito e tendono a scrivere funzioni mostruose con totale disprezzo delle misure ciclomatiche e del fermo.