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…
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 “{”!!
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
sem as gambiarras como a do thingol, que alias eh mto bem bolada
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!
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