Manifesto Anti-Else

Por um código menos complexo

O else é uma ferramenta valiosa e praticamente onipresente nas linguagens de programação, mas também um inimigo da legibilidade do programa. Entender o contexto de seu uso é fundamental para um código bem escrito e de simples manutenção, evitando o débito técnico, isto é, priorizar a velocidade da entrega em detrimento da qualidade do software.

Eventualmente, encontraremos o tal “código hadouken” com inúmeras validações emaranhadas e codependentes, tornando praticamente impossível a leitura e modificação caso necessário.

Exemplo de código Hadouken

Nesse cenário, cada adição ou alteração será uma tarefa assustadora e temporalmente custosa, resultando em uma interpretação exponencialmente complexa.

Outro ponto questionável é a ausência de informações quando se observa apenas o bloco do else, uma vez que há considerável dificuldade em inferir a função daquele trecho específico sem ler novamente as linhas prévias.

Alternativas

Na maioria dos casos, sua utilização pode ser substituída por uma forma mais concisa e de fácil compreensão, mantendo a funcionalidade:

1 — Guard Clauses (Cláusulas Guarda): Tratamento de Erro no começo da função — Garante que as linhas seguintes estarão livres de erro na variável recebida/analisada, garantindo a consistência do fluxo:

Nesse exemplo, além de tornar o trecho mais compreensível, assegura-se a possibilidade de, caso outra validação se torne necessária, adicionar verificações subsequentes sem alterar a regra de negócio acidentalmente.

2 — Early Returns: Validar o Código e retornar à medida que se atinge o resultado desejado ou se encontra um erro:

Semelhantemente ao primeiro exemplo, cria-se um último caso, após todas as outras possibilidades serem avaliadas, para que haja constância e robustez nas evaluações.

3 — Inversão de Lógica: Utilizar o valor do else como padrão, e somente sobrescrever a variável caso a condição inicial do if for válida:

Por fim, o cenário descrito acima é a base de toda a problemática discutida — ao trocar a ordem dos fatores, inevitavelmente o else será removido, não por um fator externo indecifrável, mas apenas por não fazer mais sentido na circunstância tratada.

Considerações Finais

Existem casos difíceis de se utilizar esses conceitos, como em escritas de query ou posicionamento de elementos no front-end, os quais necessitam de apenas uma das constatações, excluindo as outras possibilidades.

Há também situações em que a demonstração de vínculo entre as condições de um bloco if-else são indispensáveis na ordem estabelecida, ou até mesmo em locais nos quais não é possível usar um early return, portanto, perfomativamente, o uso do else se faz pertinente.

Finalmente, a programação orientada à diminuição do uso do else obriga o desenvolvedor a pensar em outras maneiras de projetar a aplicação e entender plenamente o fluxo em que está inserido, ao invés de aplicar uma solução temporária que englobe as outras possibilidades que nem sequer foram analisadas.

No mais, a escrita de um código limpo inicia-se nos pequenos detalhes e, quanto menos indentado for, mais legível será.

“O else não é a causa de um código mal projetado, mas a consequência dele.”