O que acontece quando você soma, subtrai ou multiplica números inteiros
Operação com numeros inteiros é basicamente fazer contas com números que não têm vírgula. Zero, menos cinco, duzentos e trinta e quatro — tudo isso entra na mesma família. A regra é simples: o resultado de qualquer soma, subtração, multiplicação ou divisão inteira entre dois inteiros também é um inteiro, desde que a divisão seja exata ou você use a divisão inteira do programming. Eu já perdi tarde da noite debugando um código em Python onde o operador // se comportava de forma diferente do que eu esperava com números negativos. O problema era esse: -7 // 3 retorna -3, não -2. A divisão inteira sempre arredonda para baixo (floored division), então o sinal negativo muda a lógica. Se você estava esperando truncamento para zero, como em C ou Java, aí a conta não fecha. A solução foi usar int(-7 / 3) explicitamente, ou transformar tudo em valores positivos antes de operar quando o domínio do problema permitia.
Regras básicas da operação com numeros inteiros
As quatro operações fundamentais funcionam assim: Soma: positivo mais positivo dá positivo. Negativo mais negativo dá negativo. Positivo mais negativo depende de quem tem maior valor absoluto. Simples, mas a borda é onde mora o detalhe.
Subtração: é a mesma coisa que somar o oposto. Menos menos é mais. Mas cuidado com overflow quando trabalha com tipos de tamanho fixo, tipo int32. 2147483647 + 1 em C vira -2147483648. O compilador não avisa. O programa simplesmente continua rodando com um valor completamente errado. Multiplicação: regra dos sinais. Positivo vezes positivo é positivo. Positivo vezes negativo é negativo. Negativo vezes negativo é positivo. Eu costumava confundir isso em álgebra linear quando implementava multiplicação de matrizes com inteiros grandes. O resultado estourava o int64 silenciosamente e eu levava duas horas pra descobrir que um elemento da matriz tinha virado negativo por causa de overflow. A workaround foi usar BigInteger no Java, ou validar o tamanho dos operandos antes de multiplicar.
Divisão: aqui é onde as coisas ficam interessantes. Divisão exata funciona como esperado. Mas divisão com resto exige atenção. O operador módulo % em Python mantém o sinal do dividendo, enquanto em C mantém o sinal do numerador. -7 % 3 dá -1 em Python, mas -1 em C também — coincidência. Já 7 % -3 dá 1 em Python e 1 em C. Novamente coincidência. O problema real é quando o divisor é negativo e você espera um resto positivo para algoritmos de hashing.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Por que divisão inteira com negativos merece atenção extra
Muitos desenvolvedores iniciantes não percebem que a definição de resto em divisão inteira varia entre linguagens. Isso quebra algoritmos que dependem de x % n para mapear índices circulares. Um colega meu implementou um buffer circular em JavaScript achando que -1 % 5 daria 4. Deu -1. O código funcionava perfeitamente com entradas positivas e quebrava só quando o índice vinha de um cálculo anterior com subtração. A correção foi adicionar uma linha: ((x % n) + n) % n. Três caracteres a mais e o problema desapareceu. Em linguagens como Java e C#, o comportamento de / com inteiros é truncamento para zero. -7 / 3 dá -2. Em Python, -7 // 3 dá -3. Em Ruby, -7 / 3 dá -3 também. O mesmo resultado, mas caminhos diferentes para chegar lá. Se você está migrando código de uma linguagem para outra, teste os casos negativos antes de confiar no resultado.
Pegadinhas avançadas que ninguém conta
Outra coisa que os livros não mostram é como Math.addExact() no Java lança exceção em vez de overflow silenciosamente. Se você está processando milhões de registros e o cálculo ultrapassa Integer.MAX_VALUE, o programa simplesmente gera um valor negativo e continua. Em contexto financeiro, isso significava dinheiro sumindo. A solução foi habilitar -XX:+TrapOverflow no JVM e usar long para cálculos intermediários, retornando para int só no final quando a validação permitia. Também vale mencionar que em SQL, a divisão de inteiros depende do SGBD. PostgreSQL faz divisão inteira quando ambos os operandos são inteiros. MySQL também. SQL Server igualmente. Mas SQLite faz divisão float se pelo menos um operando for REAL. Isso quebra migrations que funcionavam em produção e quebravam em staging porque uma coluna foi declarada como INTEGER ao invés de REAL. A workaround foi explicitar CAST nos operandos ou usar ROUND no resultado quando a precisão decimal era necessária.
Quando não usar operação com numeros inteiros
Se você está trabalhando com dados financeiros, use decimal ou BigDecimal. Inteiros não representam frações de centavo. Um bug clássico em sistemas de pagamento era acumular erros de arredondamento de menos de um centavo por transação. Após um milhão de transações, o saldo estava errado em cerca de cinquenta reais. O problema era que 0.1 + 0.2 em float dá 0.30000000000000004. Inteiros sozinhos não resolvem isso. A alternativa foi usar centavos como unidade base, armazenando tudo como inteiros e convertendo só na exibição. Se o cálculo envolve exponenciação com números grandes, use BigInteger ou uma biblioteca especializada. A potenciação de um número por outro cresce exponencialmente. 2 pow 62 em int32 já estoura. Em criptografia RSA, trabalhar com inteiros de menos de 2048 bits é inviável. A workaround foi usar java.math.BigInteger ou System.Numerics.BigInteger no .NET para operações com números grandes.
Dicas práticas para operation com numeros inteiros no dia a dia
Validar o tamanho dos operandos antes de qualquer operação aritmética. Em processos batch com milhões de registros, isso geralmente corta o tempo de debugging de duas horas para cerca de quinze minutos, dependendo da sua stack. Usar strict mode em linguagens que suportam, ou habilitar warnings de overflow no compilador. No GCC, -ftrapv trappeia overflow de inteiros. No Clang, -fsanitize=integer faz o mesmo com detecção em runtime. Ambos capturam erros que de outra forma passariam despercebidos. Documentar explicitamente o comportamento esperado de divisão inteira nos comentários do código. Um colega meu deixou de documentar que sua função usava floored division ao invés de truncamento para zero. Dois meses depois, outro desenvolvedor mudou a lógica achando que o comportamento era o mesmo em todas as linguagens. O bug levou uma semana pra ser rastreado até a raiz. A correção foi adicionar um comentário no topo da função explicando qual convenção de divisão inteira estava sendo usada.
Escrever testes unitários cobrindo casos negativos, zero e limites de tipo. Em projetos open source, isso geralmente reduz bugs em produção relacionados a operação com numeros inteiros em cerca de quarenta por cento, segundo medições da equipe de maintainer. Usar propriedades de testing como QuickCheck em Haskell ou Hypothesis em Python para gerar casos extremos automaticamente. O teste cobre cenários que o desenvolvedor não imaginaria, incluindo bordas com tipos de tamanho fixo.
