Como escolher o tipo de dado adequado

A escolha começa pelo significado

Escolher um tipo de dado não é procurar a caixa menor em que um valor cabe. É decidir o que esse valor representa, quais operações serão feitas com ele e quais estados são válidos no problema.

O código de um pedido pode conter apenas dígitos e ainda assim ser texto. O peso de uma encomenda admite fração, mas não exige a mesma exatidão de um valor monetário. Uma resposta “sim ou não” cabe em um booleano; “sim, não ou ainda não informado” já possui três estados.

Na aula sobre tipos de dados, identificamos as categorias fundamentais. Agora vamos transformar esse vocabulário em um método de decisão.

Um roteiro de decisão em sete perguntas

Antes de escrever inteiro, texto ou qualquer nome próprio de uma linguagem, responda:

1. Qual é o significado? É quantidade, medida, identificador, mensagem, condição, data ou estado?
2. Quais operações serão necessárias? Somar, ordenar, concatenar, buscar, medir duração ou apenas exibir?
3. O valor admite fração? Uma contagem costuma ser discreta; uma medida pode ser contínua.
4. Qual é a faixa possível? Há números negativos? Qual é o menor e o maior valor legítimo?
5. Qual precisão é necessária? Aproximações são aceitáveis? Casas decimais e regras de arredondamento têm significado no negócio?
6. A ausência é válida? “Não informado” difere de zero, vazio e falso?
7. Que garantias a linguagem e o sistema oferecem? O tipo existe? Qual faixa suporta? Como se comporta ao salvar, transmitir e calcular?

As respostas formam um pequeno contrato. Só então vale escolher o tipo concreto disponível na linguagem, na biblioteca ou no banco de dados.

Aparência numérica não significa quantidade

Considere dois valores: o código de pedido "0042" e a quantidade 42. Ambos usam dígitos, mas possuem papéis diferentes.

O código identifica um pedido. Não faz sentido somar dois códigos, e os zeros à esquerda podem fazer parte de sua forma oficial. Por isso, texto é uma representação coerente. A quantidade participa de soma, subtração e comparação numérica; inteiro é a escolha natural.

Pergunte: esse dado mede algo ou apenas nomeia algo? CEP, telefone, matrícula, número de documento e código de rastreio frequentemente são identificadores. Mesmo quando permitem validações específicas, não se tornam quantidades por causa dos dígitos.

Inteiro ou valor fracionário

Use um tipo inteiro quando o domínio é discreto e não admite parte fracionária: quantidade de itens, número de tentativas ou posição em uma sequência. Depois, confira se a faixa do tipo concreto comporta os extremos possíveis.

Tipos inteiros não são ilimitados. Em C#, por exemplo, byte, int e long possuem tamanhos e intervalos diferentes. Isso não significa que se deva escolher sempre o menor. Primeiro garanta correção e clareza; considere memória ou desempenho quando houver uma necessidade mensurável.

Quando o domínio admite fração, outra decisão aparece: a aproximação binária é aceitável ou a representação decimal precisa obedecer a regras exatas?

• Medidas físicas, coordenadas e resultados científicos frequentemente toleram aproximação dentro de uma margem conhecida.
• Valores monetários, taxas e cálculos contábeis podem exigir casas decimais, arredondamento definido e igualdade decimal previsível.
• Algumas soluções monetárias usam um tipo decimal; outras armazenam a menor unidade inteira, como centavos. A regra do domínio e as operações necessárias determinam a escolha.

Não existe um tipo “real” perfeito para toda situação. A documentação do Python mostra que valores como 1.1 e 2.2 não possuem representação exata em ponto flutuante binário, enquanto o módulo decimal oferece aritmética decimal com precisão e arredondamento configuráveis. Em C#, float, double e decimal também apresentam faixas, precisões e custos diferentes.

Precisão, faixa e formato são critérios diferentes

Esses três conceitos costumam ser confundidos:

Critério	Pergunta	Exemplo
faixa	quais valores mínimos e máximos cabem?	de 0 a 100.000 itens
precisão	quanto detalhe numérico precisa ser preservado?	duas casas e arredondamento financeiro
formato	como o valor será mostrado ou recebido?	R$ 19,90 na interface

Formato de exibição não deve substituir o valor interno. Símbolo de moeda, separador decimal e máscara de telefone pertencem à apresentação ou à entrada. O modelo interno precisa preservar o significado e permitir as operações do domínio.

Também não presuma que um nome conhecido ofereça as mesmas garantias em toda linguagem. O Number do JavaScript, por exemplo, representa números em ponto flutuante de dupla precisão e possui um limite para inteiros considerados seguros. Consulte a documentação do ambiente antes de depender de uma faixa ou precisão específica.

Booleano somente quando existem dois estados

Um booleano funciona bem quando a pergunta possui exatamente duas respostas válidas:

entregaExpressa ← verdadeiro
pagamentoConfirmado ← falso

Mas pagamentoConfirmado = falso pode misturar situações diferentes: pagamento recusado, pendente ou ainda não consultado. Se esses estados mudam o comportamento do sistema, modele-os explicitamente, por exemplo como pendente, confirmado e recusado.

Ausência também precisa ser intencional. Data de entrega desconhecida não é uma data vazia nem o instante zero. Um tipo opcional ou anulável pode representar “ainda não há valor”, desde que cada camada do sistema preserve essa distinção.

O mesmo cuidado vale para textos. "" é um texto presente com comprimento zero; ausência significa que nenhum texto foi informado. Se os dois estados produzem a mesma regra, talvez possam ser normalizados. Se produzem comportamentos diferentes, devem permanecer distinguíveis.

Datas e estados merecem tipos próprios

Uma data armazenada como texto pode parecer suficiente para exibição, mas dificulta ordenação cronológica, validação, cálculo de duração e tratamento de fuso horário. Quando essas operações existem, prefira os tipos de data e hora fornecidos pela plataforma e registre a regra de fuso.

Estados finitos também se beneficiam de uma representação restrita. Em vez de qualquer texto para a situação de um pedido, um tipo enumerado ou outra restrição de domínio pode aceitar somente recebido, pago, enviado e entregue. Isso impede valores como "envdio" de entrarem silenciosamente no fluxo.

Essas opções vão além dos tipos fundamentais, mas seguem o mesmo princípio: o tipo deve excluir estados inválidos sempre que a tecnologia e o custo permitirem.

Exemplo: contrato de dados de um pedido

Imagine um pedido com código "0042", três unidades, preço unitário de 19,90, peso de 1,75 kg, entrega expressa e data de entrega ainda desconhecida.

Campo	Tipo conceitual	Regra principal	Operações esperadas
codigoPedido	texto	preserva zeros; não vazio; único	comparar, buscar, exibir
quantidade	inteiro	de 1 até o limite aceito	somar, multiplicar, comparar
precoUnitario	decimal ou menor unidade inteira	não negativo; arredondamento definido	multiplicar, somar, comparar
pesoKg	ponto flutuante aproximado	positivo; tolerância conhecida	somar, comparar, estimar frete
entregaExpressa	lógico	verdadeiro ou falso	decidir prazo e custo
status	estado enumerado	somente estados permitidos	comparar, controlar transições
entregueEm	data e hora opcional	ausente antes da entrega; fuso definido	ordenar, calcular duração

O contrato não depende de sintaxe. Ao implementá-lo, consulte as garantias da tecnologia escolhida. Os artigos sobre tipos de dados em Python e tipos de dados em C# mostram como categorias semelhantes aparecem em linguagens diferentes.

Valide a escolha com casos concretos

Uma escolha plausível ainda precisa ser testada. Para cada campo, experimente:

• um valor comum;
• o menor e o maior valor permitido;
• um valor logo fora de cada limite;
• zero e valor negativo, quando fizer sentido investigá-los;
• frações com mais casas do que o esperado;
• vazio e ausência;
• um identificador com zeros à esquerda;
• operações reais do algoritmo, não apenas a atribuição inicial.

Faça um teste manual do algoritmo e registre o estado após cada operação. A escolha é adequada quando preserva os valores legítimos, impede ou detecta valores inválidos e mantém os resultados esperados.

Erros comuns ao escolher tipos

Escolher pelo exemplo atual

Um contador que hoje chega a dez pode crescer. Registre a faixa do problema, não apenas os dados de teste disponíveis.

Usar número para todo conjunto de dígitos

Isso pode remover zeros, permitir operações sem sentido e alterar identificadores longos. Comece pelo significado.

Usar ponto flutuante sem definir tolerância

Se aproximação é aceitável, declare quanto erro é tolerável e evite comparar resultados aproximados por igualdade exata sem entender as regras da linguagem.

Representar muitos estados com booleanos

Combinações como pago, enviado e cancelado podem produzir estados contraditórios. Um estado nomeado e restrito comunica melhor o ciclo de vida.

Usar valores sentinela para ausência

-1, 0 ou uma data artificial podem ser confundidos com dados reais. Modele ausência explicitamente quando ela pertence ao domínio.

Otimizar antes de medir

Escolher o menor tipo pode reduzir a faixa e aumentar a complexidade sem benefício relevante. Correção, clareza e compatibilidade vêm primeiro; otimização exige evidência.

Checklist antes de decidir

• Consigo explicar o significado sem citar a sintaxe?
• Listei as operações que o algoritmo realmente fará?
• Defini faixa, sinal e possibilidade de fração?
• Sei se o cálculo aceita aproximação e como arredonda?
• Diferenciei ausência, vazio, zero e falso?
• Restringi estados finitos quando necessário?
• Conferi as garantias da linguagem, biblioteca e armazenamento?
• Testei valores comuns, limites e entradas inválidas?

Se alguma resposta for “não”, o contrato ainda está incompleto.

Pratique

Modele os dados de uma inscrição em curso: matrícula "000087", nome, carga horária, percentual de progresso, situação da inscrição, certificado emitido e data de conclusão.

Para cada campo, registre significado, operações, faixa, precisão e ausência. Depois escolha o tipo conceitual e explique por que uma alternativa seria inadequada. Use as ideias de variáveis e constantes para criar nomes claros.

Uma solução coerente mantém matrícula como texto, nome como texto, carga horária como número não negativo, progresso com faixa definida, situação como estado restrito, certificado como lógico apenas se houver duas respostas e data de conclusão como data opcional.

O que você deve guardar

O tipo adequado é aquele que preserva o significado, suporta as operações necessárias e respeita faixa, precisão e ausência. A aparência isolada do valor não basta.

Escreva primeiro o contrato conceitual e só depois o traduza para a tecnologia. Continue em Conversão de tipos de dados para aprender a transformar valores sem esconder perdas ou falhas, ou consulte o catálogo de Lógica de Programação.

Referências

• Microsoft Learn — Integral numeric types. Acesso em 10 set. 2026.
• Microsoft Learn — Floating-point numeric types. Acesso em 10 set. 2026.
• Python Documentation — decimal: Decimal fixed-point and floating-point arithmetic. Acesso em 10 set. 2026.
• MDN Web Docs — Number.MAX_SAFE_INTEGER. Acesso em 10 set. 2026.
• Computer Science Teachers Association — Revised CSTA K–12 Computer Science Standards, Draft 3.0. Acesso em 10 set. 2026.