Clean Code — O IF ainda vive — Ep. 2: Negue o IF — mas com propósito — Early Return com Negação

Introdução

A ideia por trás do Early Return está no próprio nome: ficar o mais próximo possível do return. Em vez de prender o fluxo em if...else, você trata os casos inválidos logo no início e libera o caminho principal.

Exemplo tradicional

Regra de negócio: se o saldo for maior que 10.000, o empréstimo é aprovado. Caso contrário, é reprovado.

if Saldo > 10000 then
  EmprestimoAprovado
else
  EmprestimoReprovado;

Com Early Return e negação

if not (Saldo > 10000) then
  Exit(EmprestimoReprovado);

EmprestimoAprovado;

Note: o else desapareceu.
O fluxo inválido é interrompido no topo, e o caminho válido segue naturalmente.

Simples, direto e legível. Mas... o if ainda está ali. Preciso fazer ele desaparecer? Depende.

A regra de negócio está "incrustada"

Nesse exemplo, a lógica está dentro do código. Se ela mudar, é preciso alterar, compilar e redistribuir. Mas sejamos honestos: isso não é um problema — ao contrário do que alguns defendem para justificar a "fuga do if".

Com ou sem if, regras codificadas exigem recompilação. Simples assim.

Mas no TheCodeNaked vamos além.

Você vai ver como mudar regras sem recompilar, sem redistribuir —
mas por enquanto... segure essa ideia. A gente ainda vai chegar lá.

Sumindo com o if (mas sem mágica)

DisponibilizarEmprestimo(ProcessaAnalise(Saldo));

Agora temos um método que decide se o empréstimo deve ser liberado, baseado no resultado de uma função:

function ProcessaAnalise(Saldo: Currency): Boolean;
begin
  Result := Saldo > 10000;
end;

E podemos compor de forma ainda mais elegante:

if DisponibilizarEmprestimo(ProcessaAnalise(Saldo)) then
  ShowMessage('Seu empréstimo foi aprovado')
else
  ShowMessage('Infelizmente, seu empréstimo não foi aprovado');

Onde queremos chegar?

Você não codificou diretamente a regra.
Você passou uma decisão.

A lógica Saldo > 10000 pode estar em outro lugar:

• numa função externa;
• numa estratégia;
• numa tabela;
• ou até ser carregada dinamicamente.

O if não morreu. Ele só saiu do palco. Mas continua no script.

➕ Alternativa com atribuição direta

Disponivel := Saldo > 10000;
DisponibilizaFinanciamento(Disponivel);

Concisa e funcional — mas não é Early Return.
Atribui o resultado, mas não interrompe o fluxo.

Em algumas linguagens, é essencial garantir que variáveis estejam inicializadas antes do uso. Nem toda linguagem faz isso por você.

Outra abordagem: delegar a decisão

E quando o que muda não é só o valor, mas a forma de decidir?

DisponibilizarCredito(ProcessaAnalise);

Aqui, a lógica foi transferida para fora.
ProcessaAnalise pode ser uma função, uma estratégia, uma injeção de dependência. O if ainda existe — mas está encapsulado, isolado, intercambiável.

É como perguntar:

"Devo liberar?"

Em vez de afirmar:

"Se for maior que 10, libere."

Mas atenção: negar sempre, só se fizer sentido

Não transforme tudo em uma negação not <condição>.

Evite duplas negações ou condições que exigem interpretação filosófica:

if ((not isValid) and (not isExpired)) then
  Exit;

Isso não é clareza — é confusão.

Reflexão TheCodeNaked-style

Não existe uma única forma de decidir. A melhor abordagem depende de:

• seu contexto;
• seu time;
• a linguagem;
• o nível de clareza necessário;
• e da sua responsabilidade pela manutenção futura.

Conclusão

Early Return é uma ferramenta poderosa — mas nem sempre é a melhor escolha.

Às vezes, atribuir já basta. Outras vezes, delegar é melhor ainda. O importante não é eliminar o if. É garantir que, quando ele aparecer, ele faça sentido — e seja visto com clareza.

O TheCodeNaked não diz “negue sempre”. Mas se for negar, que seja com lucidez. E se for decidir, que seja com propósito.