Seu primeiro algoritmo completo: o troco da padaria

O problema na mesa

Este módulo abriu com a caça à ambiguidade e passou por esqueleto, pseudocódigo e fluxograma. Agora as peças se juntam num desafio de verdade: o dono de uma padaria quer parar de errar troco no fim do dia e pede um algoritmo que faça a conta. O problema parece pequeno, e é exatamente por isso que ele é perfeito: cabe inteiro na cabeça e ainda assim exige todas as habilidades do módulo. Grandes sistemas são feitos de milhares de problemas deste tamanho resolvidos com o mesmo método.

O método dos profissionais tem cinco passos, e o mais importante é resistir à tentação de pular direto para o quarto. Quem começa escrevendo pseudocódigo sem entender o problema escreve rápido e erra rápido. Quem percorre os cinco passos na ordem escreve uma vez e acerta quase sempre. Repare que os passos 2 e 3 são a aula de entrada, processamento e saída aplicada: você define as pontas antes de construir a ponte.

1. Entenda o problema: o que o dono da padaria quer, com as palavras dele?
2. Defina a saída sem ambiguidade: o valor do troco, em reais, mostrado na tela.
3. Defina as entradas: o valor da compra e o valor pago pelo cliente.
4. Escreva o pseudocódigo: leia as entradas, calcule, escreva a saída.
5. Teste com casos reais e anote o que a versão atual ainda não cobre.

Da ideia ao pseudocódigo

Com saída e entradas definidas, o processamento se revela sozinho: troco é o valor pago menos o valor da compra. Uma subtração, guardada numa caixinha de memória chamada troco pela seta <- que a lista de regras da aula 3 anunciou (o módulo 3 explora essas caixinhas a fundo). O pseudocódigo abaixo é o algoritmo completo, com comentários marcando as três partes do esqueleto. Leia linha por linha antes de seguir: você já tem todas as ferramentas para entendê-lo inteiro.

// Entrada: o algoritmo recebe os dois valores
escreva("Qual o valor da compra?")
leia(valor_compra)
escreva("Quanto o cliente pagou?")
leia(valor_pago)
// Processamento: a subtração que gera o troco
troco <- valor_pago - valor_compra
// Saída: o resultado entregue na tela
escreva("Troco: ", troco, " reais")

O algoritmo do troco, versão 1: entrada, processamento e saída marcados em comentários.

Agora execute de cabeça, como um executor literal: a compra foi de 25 reais e o cliente pagou com uma nota de 50. A primeira pergunta aparece na tela e valor_compra guarda 25. A segunda aparece e valor_pago guarda 50. A subtração calcula 50 menos 25 e guarda 25 na caixinha troco. O escreva final mostra “Troco: 25 reais”. Você acabou de rodar um programa inteiro na cabeça, com entrada, processamento e saída. É esse filme mental que separa quem lê código de quem entende código.

Teste, refine, repita

Algoritmo escrito não é algoritmo pronto: é candidato. A prova é o teste, e testar bem é variar os casos. Compra de 25, pagamento de 50: troco 25, perfeito. Compra de 30, pagamento de 30: troco 0, correto também. Agora o caso maldoso: compra de 30, pagamento de 20. O algoritmo responde, obediente, “Troco: -10 reais”. A conta está matematicamente certa e comercialmente absurda: ninguém devolve troco negativo. A versão 1 não sabe recusar pagamento insuficiente, e o teste acabou de revelar isso ANTES do cliente.

E agora? Agora nada de vergonha: anota-se o caso descoberto e planeja-se a versão 2, que precisa CONFERIR se o pagamento basta antes de calcular. Essa conferência é uma decisão, a bifurcação de sim ou não que o losango do fluxograma desenhou na aula passada e que o módulo 8 vai transformar no comando SE. Trabalhar assim tem nome, refinamento em versões, e é o jeito real de programar: a versão 1 honesta e testada vale mais que a versão perfeita que nunca fica pronta.

Faça a conta do progresso: você pegou um problema real, definiu saída e entradas, escreveu pseudocódigo executável, rodou o filme mental e encontrou um limite via teste. Isso é o ciclo completo do trabalho de programar, e você acabou de percorrê-lo inteiro pela primeira vez.