NÃO É PRECISO USAR "ELSE"⚠️
Early Return ou "retorno precoce"
O "early return" é um conceito em programação que consiste em interromper a execução de uma função ou método assim que uma condição é atendida. Isso pode melhorar a legibilidade do código e torná-lo mais eficiente.
function verificarNumero($num) {
if ($num < 0) {
echo "O número é negativo";
} else {
echo "O número é positivo";
}
}
Por exemplo, vamos supor que temos uma função em PHP que verifica se um número é positivo ou negativo e retorna uma mensagem correspondente:
function verificarNumero($num) {
if ($num < 0) {
return echo "O número é negativo";
}
echo "O número é positivo";
}
Neste exemplo, a função usa o "early return" para retornar imediatamente a mensagem correta assim que a condição for atendida. Se o número for negativo, a função interrompe a execução e retorna "O número é negativo". Caso contrário, a função continua a execução e retorna "O número é positivo".
Esse uso do "early return" torna o código mais claro e fácil de entender, além de melhorar a eficiência, pois a função não precisa continuar a execução desnecessariamente.
Só uma coisa, esse código é PHP? Porque se for, ele nem sequer chega a rodar, porque
return echodá um erro de sintaxe (mas mesmo que não desse erro, não faz sentido, porqueechosequer retorna um valor). Se a ideia é imprimir e sair, teria que serechoem uma linha ereturn;na seguinte. Enfim...
De qualquer forma, isso não necessariamente melhora a eficiência. Fiz alguns testes com JS, usando o Benchmark.js, e houve um empate técnico entre fazer com ou sem else. Testei também com Python (usando o módulo timeit) e novamente, empate técnico. Em outras linguagens meu palpite é que seria parecido (a menos que o PHP tenha algum detalhe de implementação específico).
Claro que nesse caso a função é muito simples, mas enfim, eficiência depende mais de outros fatores, como por exemplo o branch prediction - dependendo da implementação, do hardware, do algoritmo e até mesmo dos dados usados no caso real, toda essa combinação de fatores pode influenciar mais no desempenho do que se usar ou não early return.
Eu vejo o early return muito mais como uma ferramenta semântica do que algo para melhorar a eficiência. Aqui tem uma discussão bem interessante sobre o assunto, inclusive um dos casos discutidos é sobre "fail fast", ou seja, primeiro eliminar os casos de erro/inválidos, e depois partir para o "trabalho" em si. Algo como:
function fazAlgo(params) {
if (!validacao1(params)) {
return ERRO1;
}
if (!validacao2(params)) {
return ERRO2;
}
// etc (várias validações diferentes)
// se chegou aqui, é porque todas as validações passaram, então sei que os dados estão corretos
// e posso fazer aquilo que de fato a função faz
}
Outro exemplo:
public int someFunction(String name, int value, AuthInfo perms) {
int retval = SUCCESS;
if (someCondition) {
if (name != null && !name.isEmpty()) {
if (value != 0) {
if (perms.allow(name)) {
// processa os parâmetros (aqui é o que a função realmente faz)
} else {
retval = PERM_DENY;
}
} else {
retval = BAD_VALUE;
}
} else {
retval = BAD_NAME;
}
} else {
retval = BAD_COND;
}
return retval;
}
E a versão mais legível, com early return:
public int someFunction(String name, int value, AuthInfo perms) {
if (!someCondition)
return BAD_COND;
if (name == null || name.isEmpty())
return BAD_NAME;
if (value == 0)
return BAD_VALUE;
if (!perms.allow(name))
return PERM_DENY;
// processa os parâmetros (aqui é o que a função realmente faz)
return SUCCESS;
}
Nesse caso o ganho foi em legibilidade e clareza (além de deixar a manutenção mais fácil), mas não necessariamente em eficiência (pra isso precisaria testar com casos reais, e provavelmente o gargalo estaria em outra parte - raramente essa sequência de if's é o principal problema de desempenho).
E reforçando o que os demais disseram, não devemos nos apegar cegamente a esses "mantras" arbitrários do tipo "nunca use X" (ou "sempre use X"). Como qualquer coisa em computação, o mais indicado é saber como cada coisa funciona, entender seus prós e contras, e com base nisso decidir quando usar. No caso do else, que é uma das estruturas mais básicas da programação, não é diferente.
Olha... o que eu tenho dito muito entre meus colegas é que: "Existem 1000 maneiras de se preparar Neston"....
Vejo as vezes que se começa a ter um "Preconceito" muito grande com algumas paradas que... não precisa.
Um early return é muito bom, quando tu faz uma validação e tem que cair fora da função antes do tempo... mas se tu quer tomar um de dois caminhos, o else te ajuda a ter certeza que teu código não ta fazendo coisa que não devia.
Mesma coisa o switch case... troca por object literals e talz... Fica melhor com OL, fica... mas é importante tu saber do switch case, é importante conhecer essa "base" de programação. (como disse o hkupty)
Inclusive, acho que é muito importante o pessoal ter base de computação mesmo, alem de saber programar. As vezes me deparo com pessoas muito boas em certos frameworks... mas que se você trocar só a porta onde ta rodando o webapp, lascou. (Só sei acessar o webapp na 8000. Na 8008 não sei como funciona)
Não usar else pode gerar vários bug, na sua função mesmo, se o número recebido for 0 dira que o número é positivo... Early return é ideal somente para "fail fast" ou seja, para validações... o else é muito importante para garantir que todas as possibilidades estão sendo tratadas, não deixe de usá-lo.
faz tempo que nao uso o else.
Dá pra evitar ele tranquilamente. é uma das táticas do "clean code" eu acho