Já falei sobre Object Maps, uma técnica poderosa para substituir cadeias de switch ou if/else. Com ela, trocamos complexidade ciclomática por acesso direto em tempo constante (O(1)), tornando-a ideal para cenários de mapeamentos estáticos do tipo chave → valor.
No entanto, o desenvolvimento de software no mundo real raramente é tão previsível. No dia a dia, lidamos com regras de negócio dinâmicas, faixas de valores, validações combinadas e decisões dependentes de contexto, situações em que um simples mapeamento deixa de ser suficiente.
É aí que surge a dúvida inevitável:
se não consigo eliminar o if, estou condenado a escrever código sujo?
A resposta é não. Refatorar condicionais não é um esporte onde ganha quem tem menos linhas de código (se fosse assim, bastava então usar o minifier :D), mas sim quem tem o código mais claro. A proposta hoje vai além de sintaxe. A meta é parar de escrever condicionais defensivas e começar a escrever intenção.
Vamos ver como aplicar Early Return, Encapsulamento e até mesmo o polêmico Switch da maneira coerente.
O Inimigo: A Programação Defensiva
Tive um professor na faculdade que, ao ensinar lógica de programação, apresentou uma regra que ia além do que normalmente se encontra na literatura. Um if isolado é perfeitamente aceitável. Dois, talvez acompanhados de um else, ainda exigem apenas atenção. Mas, a partir do terceiro, é um sinal claro de alerta: a probabilidade de a lógica ter sido mal modelada cresce significativamente.
Em essência, o tipo de if que mais polui o código não nasce da complexidade do domínio, mas da desconfiança. É o código que, antes de executar o que realmente importa, precisa validar, checar e reconfirmar uma série de condições defensivas. O resultado é conhecido: é um Arrow Code, onde a lógica principal se perde em meio a níveis crescentes de indentação e decisões encadeadas.
// ❌ Código Defensivo e Aninhado
function processarPedido(pedido) {
if (pedido) {
if (pedido.ativo) {
if (pedido.itens.length > 0) {
if (pedido.saldo >= pedido.total) {
// Finalmente, a lógica real...
console.log("Processando...");
}
}
}
}
}
O problema aqui não é a existência da validação, mas a carga cognitiva. Você precisa ler 5 linhas de "ruído" para achar a lógica de negócio.
A Limpeza: Early Return (Guard Clauses)
A primeira estratégia para organizar a casa é o Early Return (ou Guard Clauses).
A regra é simples: trate as exceções primeiro. Se uma condição impede o código de rodar, retorne imediatamente. Isso elimina a necessidade de else e remove níveis de indentação.
// ✅ Guard Clauses: Limpando o fluxo
function processarPedido(pedido) {
if (!pedido || !pedido.ativo) return;
if (pedido.itens.length === 0) return;
if (pedido.saldo < pedido.total) return;
// O "Happy Path" fica livre e na raiz da função
console.log("Processando...");
}
Beeem melhor, neh? Mas ainda estamos lendo implementação. Estamos lendo saldo < total, quando deveríamos estar lendo uma regra de negócio.
Escrevendo Intenção (Encapsulamento)
Aqui está o pulo do gato para um código maduro. Se o seu if verifica múltiplas variáveis ou regras específicas, não exponha essa matemática na função principal. Dê um nome a ela.
Em vez de escrever código que verifica pedaços de dados, escreva código que pergunta se uma regra foi satisfeita.
// ❌ Leitura de implementação
if (user.age >= 18 && user.hasLicense && !user.suspended) {
rentCar();
}
// ✅ Leitura de Intenção (Predicados)
const podeAlugarCarro = (user) =>
user.age >= 18 && user.hasLicense && !user.suspended;
if (podeAlugarCarro(user)) {
rentCar();
}
O if continua lá. O processador vai executar a mesma comparação. Mas para quem lê (você no futuro), a complexidade foi abstraída. Você parou de ler código defensivo e passou a ler a intenção do negócio.
A defesa do Switch: Roteamento vs Lógica
Muitas vezes, a complexidade não é booleana (sim/não), mas categórica (Tipo A, Tipo B, Tipo C). Nesses casos, o Object Map do artigo anterior é ótimo, mas e se precisarmos de lógicas complexas para cada tipo?
É aqui que o switch (ou cadeias de if) costuma virar um monstro de código espaguete, violando o princípio DRY (Don't Repeat Yourself).
O segredo para usar switch sem culpa é entender seu propósito: Ele deve ser um Roteador, não um Processador.
Utilize o switch apenas como uma Factory (Fábrica). Ele decide qual estratégia usar, mas a execução da lógica fica isolada em outro lugar (Classes ou Funções).
O jeito errado (Lógica Acoplada)
function calcularFrete(tipo, peso) {
switch (tipo) {
case 'SEDEX':
// Lógica pesada misturada com a decisão
const taxa =obterTaxa();
return (peso * taxa) + 10;
case 'PAC':
// Mais lógica misturada...
if (peso > 30) throw new Error('Peso limite');
return peso * 5;
}
}
O jeito certo (Factory + Strategy)
Aqui, o switch serve apenas para escolher o especialista.
// As regras de negócio ficam isoladas (Strategy Pattern)
const FreteSedex = { calcular: (p) => (p * 10) + 10 };
const FretePAC = { calcular: (p) => p * 5 };
// O Switch serve APENAS para criar/rotear (Factory)
const obterEstrategia = (tipo) => {
switch (tipo) {
case 'SEDEX': return FreteSedex;
case 'PAC': return FretePAC;
default: throw new Error('Tipo inválido');
}
}
// Uso Limpo
const estrategia = obterEstrategia('SEDEX');
estrategia.calcular(10);
If e Switch não são o vilão
Eliminar ifs não deve ser um objetivo em si, mas o efeito colateral de um bom design.
O problema surge quando condicionais passam a compensar a ausência de estrutura, nomes semânticos e limites claros no código. Nesse cenário, o if vira defesa. O switch vira gambiarra. E a lógica de negócio se perde no meio do caminho.
Quando decisões estão bem distribuídas, Object Maps para mapeamentos estáticos, Guard Clauses para validações, Regras de negócio explícitas e Switches atuando como roteadores, o código deixa de ser reativo e passa a ser declarativo.
Você não elimina decisões.
Você elimina ruído.
E esse é o tipo de código que continua legível mesmo depois que o contexto do problema já não está mais fresco na memória.