Número De Dois Algarismos

Como validar e trabalhar com números de dois algarismos na prática

Muita gente complicada algo que é simples. Um número de dois algarismos varia de 10 a 99. Ponto. Mas quando você precisa validar isso em sistemas, planilhas ou scripts, as armadilhas aparecem rápido. A definição técnica é direta: todo inteiro inteiro entre 10 e 99, inclusive. Isso inclui 10, 47, 99, mas exclui 9 (um algarismo) e 100 (três algarismos). Em programação, você frequentemente vê isso como uma restrição de input ou um filtro em um conjunto de dados. O que as pessoas esquecem é que a validação depende de como o dado chega. Se vier como texto, "07" tem dois caracteres mas representa um número de um algarismo. Se vier como float, 10.0 passa no teste de magnitude mas não é um número inteiro de dois algarismos. Eu já perdi duas horas num pipeline de ETL porque alguém salvava códigos regionais como string e meu validador aceitava "05" como válido. A correção foi simples: converter para int primeiro, depois aplicar a faixa. Nunca confie no formato de entrada.

Métodos de validação e sua aplicação real

Existem três abordagens principais que eu uso no dia a dia. Cada uma tem seu lugar. Validação por faixa numérica: a mais comum e mais barata. Você verifica se o valor está entre 10 e 99. Em Python seria algo como `10 <= n

= 99`. Em Excel, uma fórmula de validação de dados com essa restrição. É rápido e cobre 95% dos casos. O problema é que ignora contexto. Um CEP, um código de produto, uma matrícula — todos podem ser números de dois algarismos, mas não deveria serem tratados da mesma forma matematicamente. Um zero à esquerda tem significado em alguns campos e é ruído em outros. Validação por contagem de dígitos (string): converte para texto e verifica se o comprimento é exatamente 2. Útil quando o formato importa mais que o valor. Códigos de departamento, siglas numéricas, anos abreviados. A desvantagem é que você perde a capacidade de fazer operações aritméticas sem conversão posterior, e ainda enfrenta o problema do zero à esquerda: "07" tem dois dígitos, mas é 7. Se o sistema espera 07 como identificador único, tudo bem. Se espera um valor quantitativo, você tem um bug disfarçado.

Validação híbrida: a que eu recomendo na maior parte das situações sérias. Primeiro converte para inteiro, depois aplica a faixa. Isso elimina tanto números fora do intervalo quanto strings com zeros à esquerda indesejados. Funciona assim: tenta converter, falhou — rejeita. Converteu, mas está fora de 10-99 — rejeita. Passou nos dois — aceita.

Problemas que ninguém te conta

Um caso específico que me deu trabalho recente envolvia um arquivo CSV com mais de 40 mil linhas de códigos de cidades. O campo que deveria conter números de dois algarismos tinha entradas como "02", "15", "99", "007", e até "" (vazio). Meu validador inicial, que usava apenas a faixa numérica, estava aceitando "007" porque ao converter para int virava 7 — que cai fora da faixa, então na verdade era rejeitado. O problema real era outro: "02" virava 2 e também era rejeitado, embora o sistema de origem usasse aquele formato intencionalmente. A solução foi tratar campos com zero à esquerda como um tipo diferente de validação, separando códigos de identificadores de valores quantitativos. Levei uma tarde inteira para ajustar. Outro ponto cego: números de dois algarismos negativos. -10 a -99 também têm dois algarismos significativos. Se seu campo permite negativos e você só testa `n >= 10`, vai perder metade dos dados válidos. Eu vi isso acontecer em sistemas de temperatura e saldo bancário. Sempre verifique se o domínio do seu campo inclui negativos antes de fixar um limite inferior em 10.

Limitações e quando abandon

Validar número de dois algarismos é uma ferramenta útil, mas ela não serve para tudo. Se você está trabalhando com dados reais de produção, logo vai perceber que aproximadamente 10-15% dos registros vão falhar na validação mesmo sendo legítimos — dados incompletos, codificações diferentes, formatos herdados de sistemas antigos. Nesses casos, ter um log de rejeições com o valor original e a razão da falha é mais importante do que simplesmente descartar. Eu uso uma tabela separada para registradores rejeitados, com carimbo de data/hora e valor bruto, para revisão manual em lotes semanais. Se o seu cenário exige algo além de validação simples — como gerar todos os números de dois algarismos possíveis, cruzar com outras tabelas, ou aplicar regras de negócio específicas — considere usar uma função dedicada em vez de espalhar a lógica por múltiplos lugares do código. Uma função `eh_dois_algarismos(valor)` que retorna booleano é muito mais fácil de testar e manter do que repetir a condição `10 <= int(valor)

= 99` em cinco pontos diferentes do sistema. Para quem precisa de uma solução pronta, a validação por faixa numérica com conversão prévia de tipo é o padrão que eu recomendo começar. Custa quase nada em termos de performance, funciona em qualquer linguagem, e é fácil de auditar.