[JAVA] Utilizzare più volte "return" all'interno di un metodo in base a condizioni

[hardware]

È possibile far ritornare 2 valori in 2 condizioni diverse?
Del tipo:
if(espressione)
return a;
else
return b;

[valia]

E' buona norma avere un unico punto di ritorno (quando scrivere il metodo così è semplice).

private int metodo(){
   int ret = 0; 
  // do your stuff here
   if (condizione) {
      ret = 10; 
   }else{
      ret = 12; 
  }
return ret; 
} 

questo è lecito. Come hai fatto tu ho la return dentro l'if (ma come ti ho detto sopra mi piace avere, quando posso, un unico punto di uscita)

[LeleFT]

Originariamente inviato da valia
E' buona norma avere un unico punto di ritorno (quando scrivere il metodo così è semplice).

Concordo pienamente.

Questo ragionamento è logicamente indotto anche dalla definizione di funzione: una regola che mappa N insiemi di valori (il dominio) in un unico insieme di valori (detto codominio). Una funzione, per definizione, ritorna uno ed un solo risultato. Ergo, ci dovrebbe essere uno ed un solo return.

Il tutto, inoltre, facilita la manutenzione del codice stesso: avere diversi "return" sparsi all'interno di un metodo può rendere le cose davvero complicate in fase di debug.


Ciao.

[valia]

Originariamente inviato da LeleFT
Il tutto, inoltre, facilita la manutenzione del codice stesso: avere diversi "return" sparsi all'interno di un metodo può rendere le cose davvero complicate in fase di debug.
Ciao.

A me aiuta a livello di tracciamento, quando devo loggare il valore di ritorno. In questo caso non ho ripetizioni inutili di codice (ripetizioni che aggiungo quando la return unica creerebbe codice ingestibile)

ho dimenticato una precisazione: il tipo del valore di ritorno è unico, il valore puoi deciderlo dove ti pare nel corpo del metodo, ma il tipo è unico.
non so se l'autore del thread intendeva questo con 2 valori

[Caiodark]

E' possibile farlo ma sarebbe bene evitare per i motivi descritti dai miei predecessori.
Un caso in cui si ricorre a questa tecnica è quando il valore di ritorno lo si acquisisce all'interno di cicli annidati.
Altro caso può essere la ricerca dell'ottimizzazione su programmi in real time.

E' anche abbastanza usata all'interno di blocchi try catch.

[valia]

Originariamente inviato da Caiodark
E' possibile farlo ma sarebbe bene evitare per i motivi descritti dai miei predecessori.
Un caso in cui si ricorre a questa tecnica è quando il valore di ritorno lo si acquisisce all'interno di cicli annidati.
Altro caso può essere la ricerca dell'ottimizzazione su programmi in real time.

E' anche abbastanza usata all'interno di blocchi try catch.

qui ricadi sul modo di programmare e su come scrivi le condizioni del ciclo. qualche piccolo accorgimento e non hai diversi punti di uscita (e a volte non devi usare manco break odiato da tanti).

Solo nel caso di applicazioni real-time ammetto più punti di ritorno, ma real-time + linguaggio interpretato che passa da virtual machine cozzano un po'

ps prova a dover mettere per ogni funzione un indicatore di dove entri e di dove esci, fidati che ti ingegni per non avere più di un return!!!

[Caiodark]

Originariamente inviato da valia
qui ricadi sul modo di programmare e su come scrivi le condizioni del ciclo. qualche piccolo accorgimento e non hai diversi punti di uscita (e a volte non devi usare manco break odiato da tanti).

Dipende da quanto costano questi piccoli accorgimenti in termini di tempo di esecuzione e di sviluppo. Se sono sopportabili conviene seguire la regola generale.

Solo nel caso di applicazioni real-time ammetto più punti di ritorno, ma real-time + linguaggio interpretato che passa da virtual machine cozzano un po'

Si può fare, ma il codice è diverso dal Java che si è abituati a vedere.

ps prova a dover mettere per ogni funzione un indicatore di dove entri e di dove esci, fidati che ti ingegni per non avere più di un return!!!

Basta tenere a mente che queste regole hanno costo che nell'80% dei casi val la pena pagare, a patto di applicarle bene.

[valia]

Originariamente inviato da Caiodark
Dipende da quanto costano questi piccoli accorgimenti in termini di tempo di esecuzione e di sviluppo. Se sono sopportabili conviene seguire la regola generale.

// funzione di ricerca di object secondo determinati criteri, termina appena trova object valido

Object ret = null; 
for (primo ciclo && obj != null){
  for (secondo ciclo){
     if (condizione){
           obj = valore; 
    }
  }
} 

obj != null a piacere nel primo o nel secondo ciclo. Il vantaggio di non avere codice ripetuto, break o return intermedie lo paghi a costo di un controllo (che se fatto bene è solo su obj).
In termini di prestazioni, non ho trovato sostanziali differenze tra uno e l'altro metodo (a meno di usare un pc ante-guerra).
In termini di debug...un'altro mondo!!!

Originariamente inviato da Caiodark
Si può fare, ma il codice è diverso dal Java che si è abituati a vedere.

non ho detto che non si può fare, ho detto che il pensiero di avere qualcosa di real-time passando per una vm mi fa sorridere. Java (o meglio un linguaggio managed) è poco adatto al real-time, solo questo.

Originariamente inviato da Caiodark
Basta tenere a mente che queste regole hanno costo che nell'80% dei casi val la pena pagare, a patto di applicarle bene.

Esatto, quando sei in debug ti assicuro che aiutano e tanto. Mi piacerebbe ci fosse qualcosa che in java con una macro riuscisse ad abilitare/disabilitare le tracce (la differenza in termini di prestazioni in questo caso è evidente).

[Caiodark]

Originariamente inviato da valia
obj != null a piacere nel primo o nel secondo ciclo. Il vantaggio di non avere codice ripetuto, break o return intermedie lo paghi a costo di un controllo (che se fatto bene è solo su obj).
In termini di prestazioni, non ho trovato sostanziali differenze tra uno e l'altro metodo (a meno di usare un pc ante-guerra).
In termini di debug...un'altro mondo!!!

Il costo qui è rappresentato dal ciclo interno che non viene interrotto a prescindere, inoltre se c'é più di una corrispondenza ritornerai l'ultima invece che la prima il che è contro-intuitivo ed andrebbe commentato.
Niente che un break non possa risolvere.

Esatto, quando sei in debug ti assicuro che aiutano e tanto. Mi piacerebbe ci fosse qualcosa che in java con una macro riuscisse ad abilitare/disabilitare le tracce (la differenza in termini di prestazioni in questo caso è evidente).

Di solito non ho di questi problemi, ho funzioni abbastanza asciutte e soprattutto le ho scritte io.

[valia]

Originariamente inviato da Caiodark
Il costo qui è rappresentato dal ciclo interno che non viene interrotto a prescindere, inoltre se c'é più di una corrispondenza ritornerai l'ultima invece che la prima il che è contro-intuitivo ed andrebbe commentato.
Niente che un break non possa risolvere.

infatti è solo un esempio, quel controllo se leggi bene ho detto che puoi metterlo anche nel ciclo interno (o un break come dici tu).

Originariamente inviato da Caiodark
Di solito non ho di questi problemi, ho funzioni abbastanza asciutte e soprattutto le ho scritte io.

quanto sei fortunato, questo è il caso in cui io riesco a scrivere le cose per benino