Validando dados: nunca confie no que chega de fora

Dado que vem de fora sempre pode vir errado

Imagine o cadastro da escolinha de futebol do bairro, feito num programa que você escreveu. Na primeira semana chegam fichas com idade -5, nota de avaliação física 15 (numa escala de 0 a 10) e um nome em branco. Se o programa aceitar tudo, o relatório do fim do mês sai com uma média impossível e uma criança sem nome no time. O computador, literal como você aprendeu no módulo 1, não estranha nada disso: ele calcula com o que recebeu. Estranhar é trabalho seu, e a ferramenta para estranhar de forma automática chama-se validação.

A regra de ouro dos sistemas de verdade cabe em uma frase: nunca confie na entrada. Não por má vontade com as pessoas, mas por realismo. Dedos escorregam no teclado, campos são trocados de lugar, a vírgula vira ponto, alguém preenche correndo no ônibus. Existe até um ditado clássico da computação para isso: entra lixo, sai lixo. Nenhum cálculo, por mais correto que seja, salva um dado de entrada errado. Por isso a validação vem ANTES do processamento, como o segurança confere o ingresso antes de a pessoa entrar na festa, e não depois.

O validador em pseudocódigo: o laço que insiste

O coração do validador é um padrão que você já conhece por partes: o laço ENQUANTO do módulo 9 abraçando uma condição de comparação do módulo 6. A novidade é o jeito de pensar: a condição do laço descreve o caso ERRADO, não o certo. Enquanto a idade estiver fora da faixa, o programa explica e pede de novo. Quando o dado finalmente chega válido, a condição fica falsa e a execução segue em frente, com a garantia de que dali para baixo a idade é confiável.

escreva("Digite a idade (0 a 120):")
leia(idade)
enquanto idade < 0 ou idade > 120 faça
  escreva("Idade inválida. Digite um número entre 0 e 120.")
  leia(idade)
fim
escreva("Idade registrada: ", idade)
// Digitando -5, depois 200, depois 37:
// o programa recusa duas vezes, aceita 37 e mostra "Idade registrada: 37".

O laço de validação: a condição descreve o caso inválido e insiste até o dado servir.

Repare no detalhe que separa o validador amador do profissional: usar ENQUANTO em vez de SE. Um SE conferiria apenas a primeira tentativa; se a pessoa errasse de novo, o valor ruim passaria direto. O ENQUANTO cria um portão de verdade: ninguém segue com dado inválido, seja na segunda, na quinta ou na décima tentativa. E o operador OU, que você desenhou no módulo 7, junta as duas formas de errar (abaixo do mínimo, acima do máximo) numa condição só.

Uma dica de projeto: quando um campo aparece em vários lugares (a idade entra no cadastro, na renovação e no relatório), vale transformar a validação numa função, como você aprendeu no módulo 12. Uma função validarIdade() escrita uma vez e chamada em todo lugar garante que a regra é a MESMA no sistema inteiro. Regra duplicada é regra que um dia diverge, e aí o cadastro aceita o que a renovação recusa.

Mensagens de erro que ajudam em vez de irritar

A validação tem duas metades: a lógica que barra e a mensagem que conversa. A segunda é tão importante quanto a primeira, porque quem digita não vê o seu código, vê só o texto na tela. Uma mensagem boa responde duas perguntas em uma linha: o que aconteceu e o que fazer agora. Compare “erro” com “Idade inválida. Digite um número entre 0 e 120.”. A primeira gera uma segunda tentativa no chute; a segunda resolve na hora. Sistemas respeitosos tratam o erro como parte normal da conversa, sem tom de bronca.

Guarde esta aula como alicerce do módulo: o sistema de médias, o jogo de adivinhação e o caixa eletrônico das próximas aulas só funcionam porque assumem dados já validados. É assim nos sistemas profissionais também. O aplicativo do banco confere o valor do PIX antes de qualquer outra coisa; o site de passagens valida a data antes de buscar voos. A validação é invisível quando funciona, e é exatamente essa a meta.