A regra que todo mundo esquece na hora de programar
Quando você escreve uma expressão como 10 + 5 * 2, o resultado não é 15 * 2 = 30. É 10 + 10 = 20. Multiplicação e divisão acontecem antes de adição e subtração na maioria das linguagens. Isso se chama precedência de operadores. Não é uma escolha subjetiva, é uma especificação embutida no compilador ou interpretador.
O que determina o primeiro soma ou multiplica
A precedência é definida por tabela. Cada linguagem tem a sua. Em C, C++, Java, JavaScript, Python, C#, Go, Rust — a ordem é praticamente a mesma: parênteses primeiro, depois multiplicação/divisão/módulo, depois adição/subtração. Isso não é coincidência. Vem da álgebra clássica, que herda a notação posfixa e a hierarquia operacional dos anos 1800. Em português, ensinam isso no ensino fundamental com a sigla PANDAS ou simplesmente "multiplicação antes de adição". Na prática real de desenvolvimento, o problema não é decorar a regra. O problema é que ela some em expressões grandes.
Eu já perdi duas horas debugando um cálculo de taxa de entrega em um sistema de e-commerce em 2019 porque a expressão estava escrita assim: preco_base + frete * desconto / numero_itens. O backend retornava um valor que estava 40% acima do esperado. A equipe toda achava que era um bug no banco de dados. Era precedência. A conta estava sendo interpretada como preco_base + ((frete * desconto) / numero_itens), quando o requisito era ((preco_base + frete) * desconto) / numero_itens. Eu adicionei parênteses explícitos em tudo, refiz o teste, e o valor bateu. Desde então, eu nunca confio em precedência implícita em código crítico.
Como isso funciona na prática
Vamos pegar um exemplo que parece simples mas gera confusão constante. 100 / 5 * 4. Muitos desenvolvedores iniciantes responderiam 100 / 20 = 5. A resposta correta é 80. Divisão e multiplicação têm a mesma precedência, então a avaliação vai da esquerda para a direita. Primeiro 100 / 5 = 20. Depois 20 * 4 = 80. O mesmo vale para adição e subtração: 10 - 5 + 3 não é 10 - 8, é 5 + 3 = 8.
Isso é importante porque a maioria das pessoas lê expressões matemáticas de forma visual, agrupando termos mentalmente. O computador não faz isso. Ele segue a ordem estrita da tabela de precedência associativa esquerda-para-direita para operadores de mesmo nível.
Exceções que quebram gente todo dia
Algumas situações merecem atenção especial. As mais comuns: Em Python, o operador // (divisão inteira) e % (módulo) estão no mesmo nível de * e /. Então 10 % 3 * 2 evaluate como (10 % 3) * 2 = 2 * 2 = 4, não 10 % 6 = 4. No caso específico desses dois, o resultado numérico é o mesmo por acaso, mas a lógica é diferente. Isso importa quando os operandos são negativos. -10 % 3 em Python dá 2, porque Python usa floor division. Em C ou Java, -10 % 3 dá -1. A precedência é a mesma, mas o comportamento do operador muda entre linguagens.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O operador em Python (potência) tem precedência maior que unário -. Então -3 2 é interpretado como -(3 2) = -9, não (-3) 2 = 9. Muita gente pega essa na mão. JavaScript tem uma armadilha parecida com os operadores relacionais. 1 < 2 < 3 retorna true. Por quê? Porque 1 < 2 avalia para true, que vira 1, e 1
3 também é true. A expressão não faz o que você espera. Nunca encadeie comparações assim. Use &&.
Alternativas quando a precedência natural não ajuda
Existem três abordagens razoáveis para lidar com isso no dia a dia: Parênteses explícitos. É a solução mais direta. Custa nada e elimina ambiguidade. Se o seu código depende de precedência implícita para funcionar corretamente, ele já está mal escrito. Colocar parênteses deixa a intenção clara e evita bugs quando outra pessoa (ou você daqui seis meses) ler o código.
Expressões intermediárias. Ao invés de escrever uma linha gigante, você quebra em variáveis. result_1 = frete * desconto. result_2 = result_1 / numero_itens. total = preco_base + result_2. Isso é mais verboso mas impossível de interpretar errado. Em cálculos financeiros, eu faço isso obrigatoriamente. Verificação em linguagem. Algumas ferramentas como pylint, eslint, e SonarQube têm regras específicas sobre complexidade de expressões. Configurar uma regra que rejeita expressões com mais de dois operadores sem parênteses pode ser um esforço administrativo mínimo que elimina uma classe inteira de bugs. Eu já vi times que adotaram essa política e reduziram o tempo de code review em expressões matemáticas de cerca de 5 minutos por PR para menos de 30 segundos.
O que a precedência NÃO resolve
Precedência não corrige erro de tipo. Em JavaScript, "10" + 5 * 2 resulta em "1010", não 20. O multiplicando acontece primeiro (5 * 2 = 10), mas depois a concatenação de strings domina porque o operador + é ambíguo entre soma e concatenação. Em Python, 10 + "5" gera TypeError. Você precisa converter explicitamente. Esse é um problema separado da precedência e aparece com muito mais frequência do que as pessoas admitiriam. Precedência também não ajuda em operações customizadas. Em C++, você pode sobrecarregar operadores. Em Python, você define __mul__, __add__, etc. Se sua classe de domínio redefine a semântica de + ou *, a tabela padrão de precedência ainda se aplica, mas o resultado pode não ser o esperado. Eu já vi um time implementar uma classe Money onde + fazia multiplicação (não soma) por engano, e o código passou por code review porque a precedência estava "correta" segundo a linguagem. O erro estava na semântica, não na ordem.
Resumo prático
Na dúvida, use parênteses. Sempre. A leitura de código é muito mais frequente que a escrita, e clareza mata otimização prematura. Expressões dependentes de conhecimento especializado de precedência são um passivo técnico que só gera dor no futuro. Se você está escrevendo código que será mantido por mais de uma pessoa, trate precedência como um detalhe que deve ser tornado explícito, não como um truque que deve ser explorado.
