Qual Resolver Primeiro Multiplicação Divisão Soma Ou Subtração

A regra que todo mundo decora e poucos entendem de verdade

Você já abriu uma calculadora, digitou algo como 3 + 4 × 5 e ficou esperando o resultado, certo? A maioria das pessoas erra isso na primeira tentativa. O erro não é falta de inteligência, é porque a gente cresce ouvindo PEMDAS ou BODMAS sem saber ao certo por que eles existem. A verdade prática é que a ordem de prioridade foi criada para evitar ambiguidade em expressões escritas, não por um capricho matemático. Antes disso, 3 + 4 × 5 era literalmente interpretado da esquerda para a direita por qualquer pessoa, o que gerava resultados diferentes dependendo de quem lia. O que você precisa dominar hoje é o que acontece quando os operandos se encontram. Multiplicação e divisão competem entre si no mesmo nível hierárquico, e adição e subtração também. Quando dois operadores estão no mesmo nível, a regra é avaliar da esquerda para a direita. Isso elimina o erro mais comum, que é pensar "multiplicação sempre vem antes de divisão". Não vem. Elas são equivalentes. O mesmo vale para adição e subtração.

qual resolver primeiro multiplicação divisão soma ou subtração

A resposta curta e direta é: multiplicações e divisões resolvem antes de adições e subtrações. Dentro de cada grupo, vai da esquerda para a direita. Vou mostrar com um exemplo real que eu encontrei quando estava revisando código de automação financeira de um cliente. A conta era: 1200 ÷ 24 × 3 + 50 10. A maioria dos desenvolvedores júnior que eu vi cometer o erro foi essa: resolveram 24 × 3 primeiro porque "multiplicação vem antes de divisão" na cabeça deles, chegando a 1200 ÷ 72 + 50 10 = 16,66 + 50 10 = 56,66. O resultado correto, avaliando da esquerda para a direita dentro do mesmo nível, é: 1200 ÷ 24 = 50, depois 50 × 3 = 150, depois 150 + 50 = 200, e finalmente 200 10 = 190. A diferença entre 56 e 190 é significativa quando se trata de dinheiro. Esse caso específico me fez implementar um validador de expressões no meio do projeto, porque eu sabia que outro desenvolvedor ia refatorar aquilo e provavelmente repetir o erro. Eu escrevi uma função simples que tokeniza a expressão e aplica a prioridade correta, mas o mais importante foi documentar o bug no Git com o histórico de como aquele valor incorreto havia sido propagado por três meses sem ninguém notar. Isso mostra um ponto que raramente aparece em materiais didáticos: a prioridade correta só importa quando há múltiplos operadores do mesmo nível misturados, e são exatamente esses casos que passam despercebidos em code review.

O que a matemática formal chama disso

O conceito técnico se chama precedência de operadores, e cada linguagem de programação tem uma tabela própria. Em Python, C, JavaScript e a maioria das linguagens modernas, a precedência segue o padrão: parênteses, expoentes, multiplicação/divisão, adição/subtração. O parêntese sempre vence, independente do conteúdo. Se você colocar (3 + 4) × 5, o resultado é 35, não 23, porque o parêntese redefine o fluxo de avaliação. A parte que causa confusão é quando divisões inteiras e divisões flutuantes se encontram. Em Python 3, 5 / 2 resulta em 2.5, mas 5 // 2 resulta em 2. Se sua expressão mistura / e // com *, a linguagem avalia da esquerda para a direita, e o tipo do resultado pode mudar no meio do caminho. Isso é um detalhe prático que quase nunca é explicado, mas causa bugs silenciosos em scripts de manipulação de dados. Outro ponto que vejo todo mundo negligenciando: operadores unários. O sinal de menos em -3 ^ 2. Em Python, isso é avaliado como -(3^2) = -9, não (-3)^2 = 9. Em algumas calculadoras e em MATLAB, o comportamento é diferente. Se você está trabalhando com múltiplas ferramentas, assuma que o operador unário tem precedência menor que a exponenciação, a menos que a documentação do produto diga explicitamente o contrário. Eu já perdi duas horas debugando isso em um script que alternava entre Python e Excel, porque a planilha tratava -3^2 de forma diferente do interpretador.

Erros que eu vejo todo dia no dia a dia

O primeiro erro clássico é achar que a ordem das letras em PEMDAS significa que multiplicação sempre vem antes de divisão. O M vem antes do D no acrônimo, mas na prática eles estão no mesmo nível. A mesma coisa com P e S. Isso não é uma questão de preferência, é uma questão de ambiguidade: se um sistema decidisse que M > D, expressões como 10 ÷ 2 × 5 teriam dois resultados possíveis dependendo da fonte, o que é inaceitável em qualquer padrão técnico. O segundo erro, que eu chamo de "conferência cega", é confiar na memória em vez de validar com código. Eu trabalhei num projeto onde a equipe inteira testava expressões manualmente e achava que estava certo até o ambiente de produção devolver um valor errado. A correção foi adicionar asserts em cada expressão crítica e rodar um suite de testes unitários com casos como 8 ÷ 4 ÷ 2, 6 + 4 × 2 3 e (10 2) ÷ 4 × 3. Depois disso, o índice de bugs relacionados a ordem de operações caiu para zero em seis meses. O terceiro erro que merece menção é o que acontece com grandezas físicas e unidades. Se você está calculando uma força usando F = m × a + f_atrito, e f_atrito é um valor medido experimentalmente, a precedência não muda o resultado físico, mas o erro humano ao interpretar a fórmula sim. Eu vi um relatório de engenharia onde o cálculo de tensão em uma estrutura usava 200 + 50 × 3 e o engenheiro interpretou como (200 + 50) × 3, resultando em 750 N ao invés de 350 N. A diferença parece pequena, mas em projetos de carga estrutural isso é a linha entre aprovar e reprovar um componente.

Quando a regra não se aplica

Existem cenários onde a precedência padrão não é a escolha certa. Expressões booleanas em Python, por exemplo, usam curto-circuito: if a and b or c. O and tem precedência sobre o or, então a expressão é parseada como (a and b) or c. Mas se você espera c or (a and b), o resultado pode ser diferente, especialmente quando a, b e c têm valores truthy/falsy. Eu já debuguei um sistema de permissões onde um operador or estava sendo avaliado antes do and porque um desenvolvedor não sabia dessa regra, e o resultado era acesso negado para usuários que deveriam ter acesso liberado. Outro cenário é o de expressões lambdas e funções anônimas, onde a ausência de parênteses pode levar a interpretações erradas em tempo de execução. Em JavaScript, Arrow functions seguem a mesma precedência, mas a inferência de tipos em TypeScript às vezes mascara erros de avaliação que só aparecem em runtime. A limitação mais honesta que eu posso listar é que essa abordagem de "esquerda para direita" falha quando você trabalha com notação polonesa ou árvores de sintaxe abstrata (AST). Em compiladores, a precedência é tratada por grammars recursivas, não por uma regra linear. Se você está escrevendo um parser ou uma calculadora customizada, contar apenas com a regra mnemônica vai te levar a erros em expressões compostas com mais de três níveis de aninhamento. Nesse caso, a solução é implementar uma grammar de precedência dupla (double precedence grammar) ou usar o algoritmo shunting-yard, que converte a expressão infixa para pós-fixa e elimina qualquer ambiguidade.

O que eu faria diferente se começasse hoje

Se eu fosse começar um projeto novo envolvendo cálculos complexos, a primeira coisa que eu faria é não confiar em expressões inline. Eu escreveria funções nomeadas como calculate_weighted_average(base, multiplier, adjustment) em vez de base + multiplier × adjustment. Isso elimina a ambiguidade na leitura e torna o teste unitário trivial. Em projetos grandes, expressões lineares com muitos operadores são um dívida técnica que ninguém quer pagar depois. A segunda coisa é documentar a regra de precedência no próprio código com um comentário mínimo. Não algo longo, apenas um / left-to-right for same precedence */ antes da expressão. Eu vi times inteiros perderem semanas porque um novo membro da equipe não sabia qual convenção o código antigo seguia, e a ambiguidade gerava resultados diferentes entre a documentação e a implementação. Um detalhe prático que muita gente não leva a sério: use parênteses mesmo quando a precedência já deixa claro. 3 + 4 × 5 é correto, mas (3 + (4 × 5)) deixa explícito o que você pretende, e ferramentas estáticas de análise de código como ESLint, Pylint ou SonarQube frequentemente recomendam isso. Em código legado, onde o contexto pode não estar disponível, parênteses extras são a forma mais barata de evitar erro humano.

O que eu mais vejo em projetos reais é um descaso com a portabilidade de expressões. Uma conta que funciona no Python 3 pode dar resultado diferente em JavaScript porque o tratamento de floats e divisão inteira varia entre as linguagens. Antes de deployar qualquer cálculo crítico em múltiplos ambientes, valide a mesma expressão em pelo menos dois intérpretes diferentes. Isso custa dez minutos e evita horas de debugging.