Pessoal,
isso é sinal de um bom código?
public boolean executaTalCoisa()
{
//confere se deve mesmo executar o método
if (devoSair)
{
...
resposta = false;
return (resposta);
}
//resto do método...
no meio do método tem um monte de return… do jeito que tá aqui me lembrou os GOTO de antigamente…
isso é uma boa prática?
Ao inves de
resposta = false;
return resposta;um
return false;ja da conta :).
Rafael
sim sim sim …
mas o que na verdade eu queria saber mesmo é se ficar utilizando vários return dentro do método é uma boa prática…
em vários if’s tem um return… aí que está minha dúvida.
Obrigado.
fzampa,
Concordo com você. Isto sempre me incomodou em java. É questão de costume ( será ??? )
Márcio
Sim Márcio, e nesta situacao tenho duas opcoes:
ou deixar o método cheio de returns (assim como eu o peguei) ou trocar cada return por um else…
Neste caso o método é muito, mas muito grande o que iria dificultar ainda mais a legibilidade do código.
De certo o ideal seria reescrever tudo, mas como? Utilizando os mesmos returns?
Bom, se você acha que pode dar problema com vários returns (uma das regras do PMD ou CheckStyle, não lembro qual, é justamente ter apenas um return)… então use um só. Mas obviamente se você fizer isso, vai dar problemas de compreensão de código (o seu código vai acabar ficando cheio de ifs encadeados, o que não é uma boa prática também - o PMD também reclama disso, porque o seu código ficou muito complexo).
Como muitas vezes tenho de tirar esses warnings e não tenho tempo de refatorar corretamente o código, faço a seguinte malandragem (reaproveitando seu código 
)
public boolean executaTalCoisa() {
boolean resposta = true;
exit: { // veja o tal label aqui - :-P
//confere se deve mesmo executar o método
if (devoSair) {
...
resposta = false;
break exit;
}
// resto do método...
} // o break exit é como se fosse um goto para cá:
// tratar aqui alguma coisa que tinha de ser tratada antes de retornar...
return resposta;
}[quote=fzampa]Sim Márcio, e nesta situacao tenho duas opcoes:
ou deixar o método cheio de returns (assim como eu o peguei) ou trocar cada return por um else…
Neste caso o método é muito, mas muito grande o que iria dificultar ainda mais a legibilidade do código.
De certo o ideal seria reescrever tudo, mas como? Utilizando os mesmos returns?[/quote]
Olá!
Pessoalmente eu prefiro usar return…
Não gosto de if e else por q acho que o código fica mais legível, e quanto menor for o código para mim, melhor. Por isso, sempre faço o possível para usar o returns, e criar if s que não abrem e nem fecham chaves “{”!!
Thiago
[quote]Neste caso o método é muito, mas muito grande o que iria dificultar ainda mais a legibilidade do código.
[/quote]
eu uso switch case, deixa mais legivel
Os casos em que se pode usar switch() são pouquissimos. Até pela própria sintaxe dele.
Acho (opnião/gosto) que usando return é melhor de entender…
diminui o tamanho do código e diminui obviamente o encadeamento do codigo…
e nem sempre vc pode usar switch …
Eu acho que essa discussao toda nao chegou no ponto certo da questao: se colocar apenas um return* vai deixar o seu metodo complexo demais, sera que nao ta na hora de pensar na complexidade do metodo e dar uma massageada na logica dele? Um refactoring as vezes nao responde a pergunta, mas elimina ate a existencia dela 
Concordo com vc’s, acho que o melhor seria mesmo colocar apenas um return.
Mas, como eu falei, é necessário um grande refactoring, e já pensando nisso que levantei essa questão… hj há vários returns e a leitura do código está difícil. Espero que consiga melhorar depois de colocar um return só e um boa reescrita…
[quote=fzampa]Concordo com vc’s, acho que o melhor seria mesmo colocar apenas um return.
Mas, como eu falei, é necessário um grande refactoring, e já pensando nisso que levantei essa questão… hj há vários returns e a leitura do código está difícil. Espero que consiga melhorar depois de colocar um return só e um boa reescrita…
[/quote]
Bom, se vc não entende nada no código é por que o código é uma porcaria. Não é por usar ou deixar de usar return que um código fica ilegível!
Thiago
O problema das gambiarras como a minha (break exit) é que você precisa saber usar, sem que seja uma solução para tudo.
No meu tempo de C++ havia uma outra gambiarra, mas menos poderosa (break exit consegue sair de N níveis, mas este “break” só consegue sair de um nível:)
do {
fazer alguma coisa...
if (problema) {
break;
}
mais alguma coisa...
} while (false);
mais outra coisa...
return ret;[quote=Thiago Senna]
Bom, se vc não entende nada no código é por que o código é uma porcaria. Não é por usar ou deixar de usar return que um código fica ilegível!
Thiago[/quote]
Bom, eu nao falei que não dá pra entender nada no código, apenas falei que sua leitura está difícil.
E foi justamente pensando em refatorar que vim perguntar qual a melhor situação para poder aplicar na hora certa
Ps.: Pude chegar numa conclusão:
Entre usar ou não usar vários returns utilize o bom senso
Eu prefiro um código logicamente redundante mas bem claro, do que um código logicamente perfeito e mínimo, mas não tão claro.
Não vejo nenhum problema em colocar vários returns se isso for deixa o seu código bem claro para quem vai ler depois (pode ser vc mesmo).
O ganho de performance de códigos logicamente mínimos e perfeitos é na maioria dos casos alguns ciclos de CPU a menos, o que é desprezível.
Outra coisa: é mais fácil errar numa lógica sinistra, do que numa lógica simples, ou seja, programando defensivamente na sua lógica vc minimiza bugs.
Sei lá se estou certo e sei lá se minha resposta tem a ver com a pergunta.
Me desculpem se viajei num sentido ou no outro. 