Probleminhas Com Números Inteiros

Os problemas com inteiros que ninguém te avisa antes

Você provavelmente já encontrou um bug estranho onde uma conta simples deu resultado errado, ou um valor ficou negativo do nada, e levou horas pra descobrir que era divisão inteira, estouro de tipo ou arredondamento ruim. Isso é problema com números inteiros na prática, não na teoria. A matemática é limpa, o código não é.

O cenário mais comum começa com divisão. Em praticamente todas as linguagens modernas, quando você divide dois inteiros o resultado é truncado em direção a zero. 7 dividido por 3 não é 2.333, é 2. Ponto. Se você espera arredondamento e não trata isso explicitamente, cada divisão no seu sistema acumula erro. Eu passei três dias rastreado um relatório financeiro onde os totais batiam 0.03 abaixo do esperado. Descobri que eram dezenas de divisões inteiras encadeadas sem conversão de tipo. A correção foi uma função de arredondamento adequado aplicada antes da soma final, e a troca de inteiros para decimais nos cálculos intermediários. Aqui vai algo que poucos ensinam: o operador módulo com números negativos se comporta de maneira diferente entre linguagens. Em Python, -7 % 3 resulta em 2. Em C e Java, resulta em -1. Se seu código faz migração entre linguagens ou roda em ambientes mistos, essa diferença destrói lógica de ciclagem, hash e mapeamento de índices. Eu tive um serviço de fila circular que processava tudo certo no ambiente de desenvolvimento e falhava silenciosamente na produção, que rodava numa VM com compilador diferente. A solução foi normalizar o resultado do módulo com uma função que garante sempre um valor não negativo, independente da linguagem. O terceiro ponto é armazenamento. Inteiro de 32 bits cabe no máximo 2.147.483.647. Isso parece muito até você aplicar a conta certa. Timestamps em milissegundos, IDs gerados, contadores acumulados ao longo de anos. Um sistema que eu vi processava contagem de eventos por segundo usando inteiros de 32 bits assinados. Em certo momento do deployment, o contador estourou porque a carga real era maior do que o estimado. Trocar para 64 bits resolveu, mas também expôs outro problema: algumas bibliotecas legadas do projeto assumiam 32 bits em todos os lugares e passaram a ler memória errada. A correção exigiu revisão de toda a camada de persistência, não só a variável isolada.

Como lidar com isso sem perder tempo

A primeira regra é saber qual tipo de dado sua linguagem usa por padrão. Inteiro é 32 bits ou 64 bits? Assinado ou não assinado? A resposta muda tudo. Em linguagens como Go e Rust, você declara explicitamente: int32, int64, uint8. Isso evita surpresa. Em JavaScript, todos os números são floating point de dupla precisão, o que significa que inteiros acima de 2^53 perdem precisão sem aviso. 9007199254740993 + 1 pode ser igual a 9007199254740992. É um problema que quase ninguém testa porque raramente se pensa nisso.

Se o seu sistema lida com valores monetários, pare de usar inteiros para centavos e começar a pensar em tipos decimais ou fix-point desde o início. Trabalhar com inteiros de centavos funciona bem até precisar de porcentagem, juros compostos ou conversão entre moedas. Aí a conta que era simples vira uma sequência de divisões e multiplicações com arredondamentos ambíguos. O custo de refatorar depois é sempre maior do que escolher o tipo certo desde o começo. Para validação, a prática mais útil é escrever testes com os limites conhecidos. Teste valor máximo, máximo mais um, mínimo, mínimo menos um, zero, divisões com resto, módulos com negativos. Se o sistema opera com timestamps, teste perto da virada de século e de anos bissextos. Esses casos extremos são onde os probleminhas com números inteiros aparecem, não nos valores corriqueiros que todo mundo testa primeiro. Uma última coisa: documentação. Quando você escolhe um tipo inteiro para algo, anote por quê. Escreva no código ou num arquivo de decisões técnicas que aquele campo usa int32 porque o domínio nunca deve passar de X valor, ou que usa uint64 porque precisa suportar Y escala. Da próxima vez que alguém alterar o tipo ou o sistema crescer, essa informação evita que alguém mude para int16 achando que "não vai estourar nunca" e cause um bug que leva semanas pra achar.