Numero Representado Por Tres Dezenas

Por que eu parei de calcular números de três dígitos de cabeça

No começo da minha carreira, eu gastava cerca de vinte minutos fazendo decomposição manual de códigos numéricos para validação de formulários. O sistema que eu usava na época exigia que cada número fosse representado por três dezenas — ou seja, três posições de 0 a 9, na ordem correta — e qualquer erro de digitação gerava uma inconsistência que só aparecia depois de horas de processamento. Eu achava normal, até um colega me mostrar uma planilha onde ele já havia mapeado todos os possíveis valores de 000 a 999 com seus respectivos pesos posicionais. A partir daí, o tempo caiu para algo em torno de três minutos por lote de cinco mil registros. A ideia central é simples, mas as implicações práticas são o que costumam confundir quem está começando. Um número representado por três dezenas nada mais é do que uma sequência de três algarismos, cada um ocupando uma posição de unidades, dezenas e centenas. O valor 047, por exemplo, tem zero nas centenas, quatro nas dezenas e sete nas unidades. Parece óbvio, mas a confusão aparece quando se trata de valores que começam com zero. O sistema não vê 047 como setenta e quatro. Ele vê como o valor quarenta e sete, porque o primeiro dígito é apenas um placeholder posicional. O erro mais comum que eu já vi gente cometendo é tratar o dígito à esquerda como opcional ou ignorá-lo em cálculos de validação. Isso gera problemas sérios em sistemas que usam verificação por soma ponderada ou algoritmos como Luhn adaptado para faixas de três dígitos. Se você está construindo algo assim, precisa decidir desde o início se a faixa vai de 000 a 999 ou de 100 a 999. Essas duas escolhas produzem resultados completamente diferentes em qualquer teste de integridade.

Outro ponto que as pessoas não percebem de cara: a representação por três dezenas impõe uma ordem rigorosa. Diferente de uma conjunto de dígitos, onde a permutação não importa, aqui 135 é um valor distinto de 531. Se o seu contexto exige ordenação crescente ou decrescente dos dígitos para comparação, você precisa aplicar essa transformação antes de qualquer operação de igualdade ou busca. Eu uso uma função simples que converte cada número em string, ordena os caracteres e então compara. Funciona bem para volumes pequenos. Para lotes acima de dez mil registros, eu prefiro processar em lotes de mil com um script Python que roda em paralelo.

Como eu monto a validação na prática

Minha abordagem atual começa pela conversão. Eu transformo o número bruto em uma string de exatamente três caracteres, preenchendo com zeros à esquerda se necessário. Depois, separo cada posição e aplico a lógica de negócio correspondente. Se o sistema exige que a soma dos três dígitos seja par, eu somo e verifico o resto da divisão por dois. Se exige que o dígito central seja maior que os laterais, eu comparo diretamente as três posições indexadas. O passo seguinte é a validação estrutural. Aqui eu verifico se a string resultante tem exatamente três caracteres, se cada caractere é um dígito válido e se não há caracteres especiais ou letras invisíveis que possam ter entrado pelo input do usuário. Esse último ponto é mais importante do que parece. Eu já perdi tempo caçando bugs porque um campo aceito via API vinha com um space char unicode U+00A0 no final, que não era visível na maioria dos editores. Depois da validação estrutural, eu aplico as regras de negócio. Cada regra deve ser testada isoladamente e ter seu resultado registrado. Isso facilita a depuração quando algo falha. Um log simples com o número original, a string formatada e o status de cada regra (passou ou falhou) resolve a maioria dos problemas que surgem. Sem isso, você fica adivinhando qual validação quebrou e porquê.

O caso que me fez repensar tudo sobre essa representação

Em 2022, eu recebi uma reclamação de um parceiro que dizia que cerca de oito por cento dos números que ele nos enviava estavam sendo rejeitados pelo nosso sistema de validação. Os números pareciam corretos. Tinham três dígitos. Não havia duplicação. Mas o sistema retornava erro. Passei umas seis horas testando valores manualmente até perceber que o problema estava em números como 007 e 010. Nosso validador estava tratando o primeiro zero como ausente e convertendo para inteiros antes da comparação, então 007 virava 7 e 010 virava 10, quebrando a lógica de posição. A solução foi mudar tudo para processamento baseado em string, mantendo o padding de três caracteres em todas as etapas do pipeline. A correção levou cerca de quarenta minutos de desenvolvimento e duas horas de testes unitários para cobrir todas as arestas que eu não havia considerado antes. O volume de rejeições caiu de oito por cento para quase zero — restaram apenas casos borderline que eram erros reais de digitação dos usuários finais.

Limitações que ninguém conta

Representar números por três dezenas funciona bem para muitos cenários, mas tem restrições sérias que precisam ser consideradas antes de adotar o padrão. A primeira é o limite de abrangência. Você só consegue representar valores de zero a novecentos e noventa e nove. Se o seu domínio exige números maiores, como IDs de produtos que chegam a seis dígitos, essa abordagem simplesmente não se aplica. Não adianta forçar. O correto é segmentar o número em partes ou mudar a representação. A segunda limitação é a sensibilidade a erros de digitação adjacentes. Se um usuário digita 384 quando o correto seria 394, a diferença é mínima — apenas um dígito alterado. O sistema de três dezenas não detecta esse tipo de erro automaticamente, a menos que você implemente um dígito verificador separado. Algoritmos de detecção de erros adjacentes, como os usados em CPF ou em códigos de barras EAN-13, não se aplicam diretamente a uma faixa tão pequena de valores. A terceira limitação é a questão da legibilidade. Para pessoas comuns, ler 072 como "setenta e dois" é natural. Mas em logs técnicos ou em tabelas de banco de dados, manter o zero à esquerda pode causar confusão em queries mal escritas que assumem tipo numérico. Se você estiver projetando um banco de dados, considere criar uma coluna string para o código validado e uma coluna int para o valor numérico correspondente, se for preciso fazer cálculos matemáticos em cima dele.

Alternativas quando três dezenas não bastam

Se o seu caso exige mais capacidade do que três dígitos oferecem, existem caminhos mais robustos. O primeiro é expandir para quatro ou cinco dezenas. A lógica é a mesma, apenas com mais posições e mais combinações possíveis — mil a dezena adicionada. O segundo caminho é usar códigos alfanuméricos, onde as posições podem conter letras além de números. Isso aumenta drasticamente o espaço de combinações, mas exige mudança na camada de validação e em todas as ferramentas que consomem esses dados. Um terceiro caminho, menos óbvio, é abandonar a representação posicional e usar hash ou ident. Isso elimina completamente o problema de formatação, mas torna impossível ler o valor diretamente. Se a legibilidade humana for importante para o seu fluxo de trabalho, essa opção não compensa. O que eu recomendo na maioria dos casos é testar o cenário completo antes de decidir. Pegue cem exemplos reais dos seus dados, aplique a regra de três dezenas, verifique quantos se encaixam, quantos precisam de padding e quantos simplesmente não cabem. Se mais de dez por cento dos casos não se encaixam, a abordagem precisa ser revisada antes de ir para produção.