Sull’early return nelle funzioni…

Qualche giorno fa stavo sistemando del codice quando ad un tratto mi sono (ri)messo a riflettere sul modo e sul “posto” più efficace ed efficiente per ritornare un valore da una funzione.

L’intera discussione viene spesso introdotta con i termini “early return” o anche “multiple return points“.

Per rendere le cose più comprensibili, introduco subito due piccole funzioni-esempio, concettualmente simili ma diverse rispetto al dove e al quando terminare, restituendo un valore di uscita.

La prima “versione” dichiara un valore “di ritorno” che verrà eventualmente modificato nel corso della funzione e verrà restituito “alla fine”.

La seconda invece ritorna il valore appena possibile (“early return” appunto).

bool DelayedReturnExample()
{
	bool ret = false;

	if(condition1)
		ret = true;
	else
	{
		// lots of code here...

		if(condition2)
		{
			// lots of code here...
			ret = (condition3);
		}
	}

	return ret;
}

bool EarlyReturnExample()
{
	if(condition1)
		return true;

	// lots of code here...

	if(condition2)
	{
		// lots of code here...
		return (condition3);
	}

	return true;
}

Pro

Inutile dire che le discussioni su questo tema di sprecano.

Vi rimando, ad esempio, alla domanda Is returning early from a function more elegant than an if statement? su StackOverflow.

Personalmente anche io ritengo che l’early return renda il codice più leggibile perchè rende chiara ed immediata la volontà di uscire subito e senza costringere l’eventuale “lettore” a dover scorrere tutto il codice – diramazioni degli if incluse – per capire cosa ritornerà alla fine.

Mi ritrovo quindi nella risposta di uno dei commentatori alla sopra-citata domanda:

“In most cases, returning early reduces the complexity and makes the code more readable.”

Ma tutto ha un limite…

Contro

Di contro l’early return implica che il codice può tornare in più punti (cfr. questa domanda) e ciò significa che un programmatore può trovarsi un “return” ovunque in una funzione e non solo uno alla fine.

L’abuso dell’early return, ad esempio, può rendere più complicata la fase di debug perchè poi bisogna monitorare più vie d’uscita.

Da “Top Ten Things I Gripe About In Code Reviews“:

“8. multiple return points

Up 1; we have methods with multiple return statements.

A point perhaps open to argument, but having multiple return statements in a single method make that method more difficult to read and understand. It a form of spaghetti code – and we got rid of goto for the same crime.

It can also make the code harder to debug. In an stack trace you won’t see which return statement was executed when a method ended which means that you have less of an idea what that method did and how it executed. And remember that a method might call other objects and do ’stuff’ to other ‘things’ you don’t know how much stuff happened because you don’t know what return was used.

It’s also dead-easy to write methods that only have one return statement and it doesn’t cost you anything in terms of performance. The following quote is applicable to most items in this list, it’s good here though.”

Considerazioni

Dal lato “prestazioni” non credo che seguire la strada dell’early return, allo stato attuale, ne garantisca di migliori rispetto all’altra opzione, a causa della varie trasformazioni/ottimizzazioni svolte dai moderni compilatori sul codice.

Diciamo quindi che, supponendo simili le prestazioni delle due forme, quella che fa uso dell’early return tende a rendere il codice più compatto (meno righe di codice, meno “graffe”, …) e, se vogliamo, ad agevolare il programmatore che deve rileggere il codice.

Inoltre il buon programmatore sa che le funzioni, di norma, non devono mai superare un certo numero di righe (qualcuno dice 20, altri 50, altri ancora 100, ma il succo del discorso è riassumibile in “poche righe e senza cadere nella sindrome APL“) per cui il problema tende a spostarsi dalla singola funzione all’eventuale marasma di funzioni che si chiamano fra loro.

Ne farei quindi più un discorso di gusto, stile/eleganza e manutenibità che di efficienza in senso stretto.

Sui gusti non si disputa ma l’importante è che il codice risulti il più possibile coerente e non ci siano continui cambi di metodo di ritorno fra una funzione e l’altra: la coerenza conta!

Sull’eleganza/stile, credo che sia il codice risultante a determinare la scelta.

Ci sono casi in cui l’early return riesce a rendere facile la lettura da parte del programmatore ma anche tediosa e frustrante la fase di debug a causa dei troppi breakpoint: la leggibilità è fondamentale, ma non a scapito della possibilità di debuggare, estendere e manutenere facilmente il codice!

Visione “mentale”

Però secondo me c’è dell’altro…

Tornando alle mie due piccole funzioni e tralasciando ogni considerazione a livello di prestazioni, quale delle due forme vi pare più chiara relativamente al test su condition1?

Sarà la mia visione, ma l’utilizzo accorto dell’early return mi trasmette la volontà del programmatore di uscire appena possibile, appena è certo che un risultato non cambierà: se devo leggere del codice per la prima volta e ogni if equivale a suddividere il problema in più sottoproblemi, allora l’early return mi implica chiudere subito il relativo sottoproblema, almeno a livello mentale.

Una cosa chiusa in quel modo, “brusco”, lo è definitivamente, anche nella mia testa. Per cui potenzialmente si riduce anche il numero di diramazioni, casi e sottocasi che dovrò tenere a mente mentre “esploro” il codice.

In termini “accademici”, pensando al codice e alle sue diramazioni come ad un albero (albero di decisione?), l’early return permette di arrestarmi/potare un sottoalbero istantaneamente e non costringermi ad esplorarlo (potenzialmente) tutto, giusto per capire cosa ritorna alla fine. Questo ovviamente a livello mentale.

Ovviamente se la funzione è piccola questo discorso è meramente formale, “da accademia” appunto.

In conclusione

Morale della fiaba: se/quando posso, tendo ad impiegare l’early return ma imponendomi un limite. Se la funzione è lunga al più una cinquantina di righe, al massimo ammetto 3-4 punti di uscita immediata. Metterne di più significa rischiare di complicare troppo le cose sotto ogni punto di vista…

Voi che ne pensate?