Newsgroup: it.comp.java
Titolo: return nel bel mezzo di un for

Ciao a tutti,
è cattiva programmazione chiamare return nel corpo di un for? se
siperchè?

 siperchè?
Seconde me il return dovrebbe per quanto possibile stare alla fine del 
codice,almeno si riesce a capire il punto di uscita del programma o 
della routine.
In fase di debugging o di modifica dei sorgenti, avere dei return messi 
a muzzo qua e là può rendere poco comprensibile il codice.
bye!
-- 
elimina unsampdoriano per rispondere via email

 siperchč?
Non e' bello, ma in alcune circostanze puo' avere senso.
Per esempio se ti devi smazzare un array o una lista o qualcosa, e devi 
uscire con l'oggetto trovato o col not found, allora in quel caso un 
return nel ciclo di for e' la cosa piu' efficiente: quando lo trovi, 
return, altrimenti quando il ciclo e' finito, return not found.
Tuttavia, a parte queste eccezioni, e' una cosa da evitare piazzare dei 
return in posti strani, e se lo fai, lo evidenzi con un bel commento!

 siperchč?
credo sarebbe piů corretto interrompere l'elaborazione del ciclo, con un 
break, e fare arrivare alla fine la funzione...

 break, e fare arrivare alla fine la funzione...
se hai a che fare con dei cicli annidati c'e' la possibilita' di usare
Break come forma di GOTO.
break label; e' la forma da utilizzare e label deve essere
un'etichetta definita prima del loop, altrimenti restituisce errore in
fase di compilazione. Non e' come utilizzare il GOTO e in alcuni casi
e' una scelta corretta. Come in questo caso per uscire da una serie di
cicli annidati.
r.

 r.
per uscire da un unico ciclo basta semplicemente il break.
Quello che suggerisci tu, ovviamente vale nel caso di piů cicli annidati.

 Quello che suggerisci tu, ovviamente vale nel caso di più cicli annidati.
infatti specificavo, nel caso di cicli annidati. :)
r.

ryuujin ha scritto:

si, certo, scusami tu, non avevo letto bene....
:)

 siperchè?
diciamo che non è una best practice perchè aggiunge un punto di uscita
inaspettato al metodo. ne risentirà la manutenibilità del codice.
se si può evitare è meglio.

 ha scritto nel messaggio 
news:1891cfd8-6c80-4f68...@i29g2000prf.googlegroups.com...



Dipende :-)
Non credo che sia un "punto di uscita inaspettato", almeno dal punto di 
vista formale: in fondo un return in un ciclo restituisce il controllo al 
metodo chiamante restituendo il valore previsto: al chiamante non importa 
( o non dovrebbe importare...) nulla sul come il chiamato sia stato 
codificato... o no ?
Scorpio. 

Scorpio ha scritto:

al chiamante no, ma al...modificante sì :-)
Prova a prendere un pezzo di codice scritto ad minchiam dopo sei mesi 
che non lo tocchi più, oppure scritto da altri e poi ne riparliamo ;-)


ho visto consigliare "punti di uscita" in testa a metodi proprio per 
chiarezza,
esempio:
public void doSomething(String param)  {
    if (param==null) {
        throw new IllegalArgumentException("param e' null");
    }
    ...
}
oppure:
public boolean doSomething(Object o) {
    if (o == null) {
        return false;
    }
    ....
    return true;
}

 writes:
GC> In fase di debugging o di modifica dei
GC> sorgenti, avere dei return messi a muzzo qua e là può rendere poco
GC> comprensibile il codice.  bye!
Se sono veramente messi a nuzzo allora tutto il codice ha problemi...
GC> -- elimina unsampdoriano per rispondere via email
Non si poteva eliminare ungenoano :) :) :) :) ?
-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                   e coltivatore diretto               not install
                               di software                   Debian"
a Cesare avrei detto di scrivermi | I would have told Caesar to write
a 
fn...@rat.vg
                    | me at 
fn...@rat.vg

> siperchè?
r> diciamo che non è una best practice perchè aggiunge un punto di
r> uscita inaspettato al metodo.
Inaspettato ?????????????????????
Piuttosto che dover aggiungere test su come si è uasciti dal ciclo per
condizionare l'esecuzione di codice dopo il for, meglio il return.
Se invece dopo il ciclo si esce subito, a mettere un break non si spende
tanto di più...


 siperchè?
Ci si aspetta di trovare il return alla fine della funzione. Io di
solito imposto una variabile (RetVal) che funga da valore di ritorno
della funzione e cambio questo valore all'interno della funzione
stessa (cicli, if, ec..) e metto il return sempre alla fine, dove il
programmatore si aspetta che ci sia.
Discorso analogo per i break/continue. Preferisco evitarli per quanto
possibile.
Ciao,
    Fabrizio
-website: 
http://www.negusweb.it