Função Do Que E Do Se

Controlando fluxos condicionais em JavaScript: o que e quando usar

Você já tentou debugar uma função que não executa o caminho que deveria e descobriu que o problema era uma condição `if` mal escrita? Isso acontece muito quando gente nova entra no desenvolvimento web. A confusão entre diferentes estruturas de controle é comum, e entender isso faz diferença no dia a dia. O conceito central aqui gira em torno de duas construções: o `if` para verificação simples e o `switch` para múltiplas opções. Muita gente acha que são intercambiáveis, mas não são. O `if` verifica uma condição booleana. O `switch` compara uma expressão contra múltiplos casos. Vou mostrar como usar cada um na prática. Eu trabalho com JavaScript há anos e já vi projetistas escreverem listas enormes de `else if` quando um `switch` resolveria em décimos do tempo. O segredo não é memorizar regras, é sentir quando cada estrutura se encaixa. Vou dar exemplos reais do meu dia a dia.

Cenário simples: você precisa verificar se um valor está dentro de um intervalo.

function verificarStatus(valor) {
  if (valor < 0) {
    return 'negativo';
  } else if (valor === 0) {
    return 'neutro';
  } else {
    return 'positivo';
  }
}

Aqui o `if` com `else if` faz sentido porque estamos lidando com faixas de valores, não casos discrete. Agora veja quando usar switch: Percebeu a diferença? No primeiro exemplo, comparamos ranges. No segundo, comparamos valores exatos de uma enumeração. Misturar isso gera código confuso e difícil de manter. Uma vez eu escrevi uma função que precisava lidar com tipos de arquivos: PDF, JPG, PNG, MP4, MP3. Eu usei `if` encadeados com 12 ramificações. O código tinha 80 linhas. Refatorei para `switch` e caiu para 25 linhas. A legibilidade melhorou drasticamente.

O erro mais frequente que vejo é usar `if` para comparações de igualdade quando `switch` seria mais claro. Também é comum esquecer o `break` no switch, fazendo com que todos os casos subsequentes sejam executados. Isso se chama "fall-through" e pode causar bugs difíceis de rastrear.

// ERRO: esqueceu o break
switch (tipo) {
  case 'A':
    fazerAlgo();
  case 'B':
    fazerOutraCoisa(); // executa mesmo quando tipo é 'A'
    break;
}

Solução: sempre coloque `break` exceto quando quiser fall-through intencional, e nesse caso documente claramente. Muita gente se preocupa com performance desnecessariamente. Para a maioria dos casos, a diferença entre `if` e `switch` é irrelevante. O V8 otimiza switch para tabelas de salto quando há muitos casos, o que pode ser mais rápido. Mas não otimize prematuramente. O que realmente impacta performance é o que você faz dentro da condição. Verificações de string com `===` são mais rápidas que regex. Cache de resultados evita recálculos. Essas decisões importam mais que a estrutura de controle em si.

Casos edge que todo mundo esquece

Valores `null`, `undefined` e `NaN` causam problemas estranhos. O `switch` trata `null` e `undefined` como casos separados, mas `NaN` nunca é igual a si mesmo. Se você precisa verificar NaN, use `Number.isNaN()`. Também tem o caso de tipos misturados. `switch` usa comparação estrita `===`, então `"1"` não é igual a `1`. Isso já me pegou várias vezes quando vinha dado de API.

Minha recomendação prática

Use `if` quando:

• Verificar ranges ou condições complexas
• Tiver apenas 2-3 ramificações
• Precisar de lógica booleana sofisticada

Use `switch` quando:

• Tiver múltiplos valores discretos para comparar
• O código base for uma enumeração
• Querir melhorar legibilidade com muitos casos

Conclusão sobre função do que e do se

Entender a função do que e do se no contexto de estruturas condicionais não requer teoria avançada. Requer prática e experiência com erros reais. Comece escrevendo código feio, descubra os problemas, e refatore. É assim que se aprende de verdade. O importante é saber quando cada ferramenta se encaixa e evitar armadilhas comuns como fall-through acidental e comparações de tipo misturado.