ValorFinal
Entrar

Módulo 16 - Projeto final, pensando como programador

Parte 1: a entrada que não deixa passar dado ruim

8 min de leitura · por Cesar Gargiulo, revisado pela equipe ValorFinal e GuardiaSec · Atualizado em 02/07/2026

O que você vai aprender

  • Escrever a leitura das três entradas do projeto: quantidade, valor e categoria.
  • Proteger cada leitura com um laço de validação ENQUANTO.
  • Escrever a condição do laço olhando para o dado ERRADO, não para o certo.
  • Reconhecer o padrão pergunta, laço de rejeição, dado limpo.

A porta de entrada do programa

Existe uma frase antiga da computação que resume esta aula: entra lixo, sai lixo. Se o usuário digitar uma despesa de valor zero, negativo ou uma categoria que não existe, nenhuma conta lá na frente conserta o estrago; o relatório final nasce contaminado. Por isso a primeira parte do projeto é uma porta de entrada com segurança: cada informação é conferida na hora, e o que estiver errado volta para o usuário com um aviso claro. É o mesmo papel do porteiro do prédio: ninguém sobe sem se identificar, e quem mora lá em cima pode confiar em quem chega.

escreva("Quantas despesas você quer registrar?")
leia(quantidade)
enquanto quantidade < 1 faça
    escreva("Preciso de pelo menos 1 despesa. Tente de novo.")
    leia(quantidade)
fim

// O programa só passa deste ponto com quantidade >= 1

A primeira porta: a quantidade de despesas precisa ser pelo menos 1.

Leia o laço com calma, porque ele carrega o segredo da aula. A condição do ENQUANTO não descreve o dado certo; descreve o ERRADO. Enquanto a quantidade for menor que 1, o programa reclama e pergunta de novo. No dia em que o usuário digitar 5, a condição vira falsa, o laço termina e a execução segue. Esse desenho tem um nome informal carinhoso: laço de rejeição. Ele é a aplicação direta do ENQUANTO do módulo 9 com a validação do módulo 14, agora a serviço de um projeto de verdade.

O valor da despesa: maior que zero, sem choro

Dentro do laço principal (que se repete para cada despesa, como você verá na montagem final), a primeira pergunta é o valor. As regras do requisito são simples: despesa de valor zero não é despesa, e valor negativo não faz sentido neste programa. Logo, a condição de rejeição é valor <= 0. Repare como o requisito escrito na aula 1 virou uma linha de condição: é assim que planejamento e código conversam. Quando o requisito é claro, a condição praticamente se escreve sozinha.

escreva("Valor da despesa em reais:")
leia(valor)
enquanto valor <= 0 faça
    escreva("O valor precisa ser maior que zero.")
    leia(valor)
fim

// Daqui para a frente, valor é sempre positivo

O laço de rejeição do valor: só passa despesa maior que zero.

🎮 Jogo da aula

O porteiro que barrou os inocentes

Este trecho deveria aceitar apenas valores maiores que zero, mas uma linha inverteu a lógica do porteiro. Toque a linha com o bug.

O bug do jogo é o erro mais cometido em validação, e não só por iniciantes: inverter a condição do laço. A dica para nunca cair nele é ler o ENQUANTO em voz alta como uma frase de porteiro: “enquanto o dado estiver errado, devolvo a pergunta”. Se a frase que sair for “enquanto o dado estiver certo, devolvo a pergunta”, o alarme deve tocar. Um teste de mesa de trinta segundos com um valor válido e um inválido também desmascara a inversão na hora.

A categoria: só existem quatro opções

Falta a terceira entrada: a categoria da despesa. O organizador trabalha com um cardápio fechado de quatro opções numeradas: 1 para moradia, 2 para alimentação, 3 para transporte e 4 para outros. Qualquer número fora desse intervalo é rejeitado, e aqui a condição precisa de duas comparações unidas pelo OU do módulo 7: a categoria está errada quando é menor que 1 OU maior que 4. Uma só das duas ser verdadeira já basta para devolver a pergunta.

escreva("Categoria: 1 moradia, 2 alimentação, 3 transporte, 4 outros")
leia(categoria)
enquanto categoria < 1 ou categoria > 4 faça
    escreva("Opção inválida. Digite um número de 1 a 4.")
    leia(categoria)
fim

// Daqui para a frente, categoria é 1, 2, 3 ou 4

Cardápio fechado: a categoria só passa se for 1, 2, 3 ou 4.

Com as três leituras protegidas, a parte 1 está pronta e testada: quantidade maior ou igual a 1, valor positivo e categoria entre 1 e 4. Esse é o contrato que ela assina com o resto do programa. Na próxima aula, a parte 2 vai receber esses dados sem desconfiar de nada, e é essa confiança que deixa o código dela limpo: nenhum SE extra para revalidar, nenhuma gambiarra defensiva. Cada parte faz o seu trabalho uma única vez, e bem feito.

Teste rápido

No laço de validação “enquanto valor <= 0 faça”, o que a condição descreve?

Perguntas frequentes

Por que validar na entrada em vez de conferir na hora de somar?
Porque a validação na entrada acontece uma única vez, num lugar só, e todo o resto do programa herda dados confiáveis. Conferir na hora de somar espalharia SEs defensivos por todo o código, e bastaria esquecer um para o bug nascer. Porta bem guardada dispensa vigia em cada cômodo.
E se o usuário digitar uma letra em vez de número?
No pseudocódigo do curso assumimos que leia devolve um número, para manter o foco na lógica. Nas linguagens reais existe uma conferência extra de tipo (texto versus número) antes da faixa, e a estrutura é a mesma: um laço que repete a pergunta até o dado servir.
O laço de validação pode rodar para sempre?
Pode, se o usuário insistir em digitar errado, e nesse caso é o comportamento desejado: o programa não segue com dado ruim. Diferente do laço infinito acidental do módulo 9, aqui a saída existe e está nas mãos do usuário: basta digitar um dado válido.
Por que a condição da categoria usa OU em vez de E?
Porque a categoria está errada em dois cenários diferentes: menor que 1 OU maior que 4. Basta um deles ser verdadeiro para rejeitar. Com E, a condição exigiria que o número fosse menor que 1 e maior que 4 ao mesmo tempo, o que nenhum número consegue, e o laço nunca rodaria.
Devo validar a quantidade máxima de despesas também?
É um refinamento excelente. Um teto como 100 despesas evita sessões intermináveis e mostra maturidade de quem pensa em casos extremos, como no módulo 13. A condição vira: enquanto quantidade < 1 ou quantidade > 100. O projeto base pede só o mínimo de 1.
Posso escrever as três validações como uma função?
Pode e é o caminho natural depois do módulo 12: uma função lerNumeroValido(mensagem, minimo, maximo) elimina a repetição dos três laços. No projeto base mantemos os laços visíveis para você enxergar o padrão; a versão com função é um desafio proposto na aula 5.

Fontes

Seu progresso fica salvo neste aparelho. Assinantes sincronizam entre os aparelhos.

← Planejando o projeto: o organizador de despesas Concluir e avançar →