Trabalhando com números decimais em sistemas legacy
Muita gente trava quando precisa manipular valores como dezessete e cento e setenta e cinco milésimos em planilhas ou scripts. A parte mais chata não é o conceito em si, mas as armadilhas que aparecem na prática. Vou explicar como eu lido com isso, direto ao ponto.
dezessete e cento e setenta e cinco milésimos na prática
O número em si é simples: 17,175. O problema começa quando você tenta usá-lo em sistemas que não foram projetados para decimals precisos. Já vi gente perder horas porque uma conversão de float perdeu três casas decimais sem avisar. Em Python, por exemplo, 17.175 pode virar 17.174999999999997 dependendo de como é tratado. Use a biblioteca decimal se precisar de precisão. No meu trabalho com sistemas financeiros antigos, me deparei com uma situação em que um relatório gerava valores arredondados de forma inconsistente. Um cliente tinha um contrato em que o valor unitário era exatamente esse tipo de decimal com três casas. Quando o sistema somava múltiplas linhas, o erro acumulava centavos que pareciam nada, mas em volume alto viravam diferença significativa. A solução foi forçar o arredondamento com round(value, 3) em cada operação intermediária, não só no resultado final.
Isso parece óbvio, mas a maioria dos tutoriais ensina o caminhoinverse. Eles mostram o resultado final arredondado e dão como resolvido. O custo real está nas contas do meio.
Como formatar e converter corretamente
Em JavaScript, se você precisa trabalhar com esse valor, evite parseInt ou parseFloat para cálculos financeiros. UseNumberFormat ou mantenha tudo em centavos/inteiros até o momento da apresentação. Um workaround comum é multiplicar por 1000, trabalhar com inteiros, e dividir só na saída. Em planilhas Excel ou Google Sheets, o problema é diferente. O decimal padrão do sistema pode exibir 17,175 como 17,17 ou 17,18 dependendo da formatação celular. Sempre verifique a quantidade de casas decimais configuradas na célula antes de confiar no que vê na tela. A função ROUND(value, 3) resolve, mas só se aplicada em todas as fórmulas da cadeia, não apenas na última.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outra coisa que poucos mencionam: ao importar dados de CSV ou bases de texto, o separador decimal varia entre países. Um arquivo vindo dos EUA pode usar ponto (17.175), enquanto o padrão brasileiro é vírgula (17,175). Se você não tratar essa conversão explicitamente, vai ter valores completamente errados e nem percebe no primeiro olhar. Use replace na string antes de converter para número.
Pegadinhas avançadas
Se você está lidando com APIs ou transferências de dados entre sistemas, o formato JSON pode truncar decimais. Alguns parsers removem zeros à direita automaticamente, transformando 17,175 em 17.175 ou até em 17.17 dependendo da implementação. Sempre valide o schema de entrada e saídata antes de confiar nos valores recebidos. Em bancos de dados, o tipo FLOAT ou REAL tem limitações de precisão por padrão. Para valores monetários ou técnicos que exigem três casas decimais exatas, use DECIMAL ou NUMERIC com precisão definida. Eu já vi um sistema inteiro quebrar porque um desenvolvedor escolheu DOUBLE para armazenar valores que depois precisavam ser comparados exatamente. A comparação de floats nunca é segura sem uma margem de erro controlada.
O down side é que DECIMAL/NUMERIC pode ser mais lento em aggregações massivas. Se o seu throughput é crítico e você está processando milhões de linhas por segundo, o ganho de precisão pode custar performance. Nesse caso, o workaround é manter os dados brutos em DECIMAL e fazer as contagens pesadas em uma camada pré-processada com valores em inteiros (multiplicados por 1000).
Um exemplo completo de fluxo correto
Vamos supor que você receba um CSV com valores como 17,175 em uma coluna de preço. O fluxo que eu recomendo é: Leia a string original. Substitua vírgula por ponto se necessário. Converta para decimal com precisão definida, não para float. Realize todos os cálculos nessa precisão. Só formate para exibição no final, usando a casa decimal apropriada.
Qualquer desvio disso tende a gerar erros silenciosos que só aparecem meses depois, quando alguém percebe que os totais não fecham. Não adianta corrigir depois. O custo de refazer importações e reprocessar dados históricos é muito maior do que configurar o fluxo certo desde o início. Se o seu sistema não permite mudar o tipo de dado das colunas existentes, aí a coisa fica mais complicada. Nesse caso, uma tabela intermediária com conversão controlada costuma ser a única saída viável sem risco de corromper registros já existentes.
