Nos programas de verdade a ambiguidade também aparece?

Aparece antes do programa: na conversa. Boa parte dos bugs nasce de pedidos ambíguos, como “o sistema deve avisar o cliente rapidamente”. Rapidamente é quanto? Por qual canal? Programadores experientes gastam tempo transformando pedidos vagos em regras exatas antes de escrever qualquer linha.

Como sei se o passo está pequeno o bastante?

Pergunte se o executor cumpre o passo sem decidir nada sozinho. Se cumpre, o tamanho está bom. Para o computador, os passos precisam chegar ao nível de comandos como “mostre esta mensagem” e “some estes dois números”; é o zoom máximo, e o pseudocódigo da aula 3 foi feito para escrever nesse nível.

Não é pedantismo exigir tanta precisão?

Entre humanos, seria. Nós preenchemos lacunas com bom senso o tempo todo, e a conversa flui. O computador não tem bom senso para preencher nada, então a precisão deixa de ser frescura e vira o idioma. A boa notícia: esse treino melhora até a comunicação entre pessoas.

Qual a diferença entre esta aula e a instrução clara do módulo 1?

O módulo 1 mostrou O QUE é uma instrução clara e por que a máquina exige isso. Esta aula ensina COMO produzir clareza: identificar as palavras que criam ambiguidade, trocá-las por medidas e ajustar o tamanho de cada passo. É a mesma ideia saindo do diagnóstico para a prática.

E quando o executor é uma pessoa, como numa receita de família?

Aí você pode relaxar o zoom, porque pessoas completam lacunas. Mas repare como manuais bem escritos, bulas e procedimentos de segurança usam o padrão do algoritmo: medidas exatas, uma ação por passo, ordem numerada. Quanto maior o custo do erro, menos ambiguidade se tolera.

Existe ambiguidade impossível de eliminar?

Em linguagem natural, sempre sobra alguma, e é por isso que as linguagens de programação existem: nelas, cada comando tem um significado único, sem sombra. O pseudocódigo do curso fica no meio do caminho, com português na aparência e disciplina de máquina na estrutura.

Módulo 2 - Algoritmos, as receitas do computador

Passo a passo sem ambiguidade: o fim do “depende”

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

Velocidade

O que você vai aprender

Reconhecer as palavras que denunciam ambiguidade num passo.
Reescrever passos vagos como ações únicas e verificáveis.
Quebrar tarefas grandes em passos do tamanho certo.
Aplicar o teste do executor distraído em qualquer receita.

Onde a ambiguidade se esconde

No módulo 1 você aprendeu que algoritmo é uma sequência finita de passos claros. Agora começa o ofício: escrever esses passos de verdade. E o primeiro inimigo tem nome, ambiguidade. Pense na receita da avó que diz “farinha até dar o ponto”. Para ela, funciona, porque o ponto mora na mão dela. Para você, que nunca fez aquela massa, a instrução é uma charada. Um algoritmo bem escrito não pode depender do que mora na cabeça do autor: tudo o que importa precisa estar no papel.

A ambiguidade adora se esconder em dois lugares: nos adjetivos e nas quantidades vagas. “Asse até dourar” depende do que cada pessoa chama de dourado; “asse por 35 minutos a 180 graus” é igual para todo mundo. “Adicione sal a gosto” funciona entre cozinheiros; “adicione meia colher de chá de sal” funciona até para um robô. Repare que a versão precisa não é mais difícil de escrever, é só mais honesta: ela obriga o autor a decidir aquilo que a versão vaga empurrava para o executor decidir.

Passo ambíguo (cada um faz de um jeito)

Bata a massa até ficar boa.
Regue as plantas quando precisar.
Espere um tempinho antes de abrir a panela.

Passo sem ambiguidade (todos fazem igual)

Bata a massa por 3 minutos em velocidade média.
Regue as plantas com 300 ml de água a cada 2 dias.
Espere 10 minutos antes de abrir a panela.

O tamanho certo de cada passo

Existe uma segunda forma de ambiguidade, mais sorrateira: o passo grande demais. “Faça o bolo” é um passo perfeito para uma confeiteira e um enigma para quem nunca ligou o forno. Esse tamanho do passo tem nome técnico, granularidade. A regra prática é simples: quebre o passo até que cada pedaço descreva UMA ação que o executor cumpre sem decidir nada sozinho. “Troque o pneu” vira “puxe o freio de mão”, “solte os parafusos com a chave de roda”, “posicione o macaco na marcação da longarina” e assim por diante.

🎮 Jogo da aula

Caça à ambiguidade

Esta receita de café tem quatro passos sem ambiguidade e um que depende de interpretação. Toque no passo que reprovaria num algoritmo.

O jogo revela um detalhe importante: a linha ambígua não parece errada à primeira vista. Ela soa natural, porque é assim que a gente fala. O treino de programador é justamente esse: reler o que soa natural com desconfiança profissional. Vale registrar também o exagero contrário. Quebrar “pegue a xícara” em “estenda o braço, abra os dedos, feche os dedos” é granularidade demais para um executor humano. O zoom certo é o menor que o SEU executor precisa, nem mais, nem menos.

O teste do executor distraído

Antes de dar qualquer algoritmo por pronto, aplique o teste do executor distraído: releia cada passo fingindo ser alguém que não sabe nada do assunto, não adivinha intenção e cumpre ordens ao pé da letra, exatamente como o computador literal do módulo 1. A cada passo, pergunte: eu conseguiria cumprir isso sem inventar nada? Se a resposta tiver um “depende”, você achou um defeito antes de ele virar bug. Esse hábito de revisar fingindo ser a máquina vai valer ouro no teste de mesa do módulo 13.

Leia o passo em voz alta fingindo não saber nada do assunto.
Pergunte: duas pessoas diferentes fariam exatamente a mesma coisa?
Ache a palavra que abre espaço para interpretação (“bom”, “um pouco”, “quando precisar”).
Troque a palavra vaga por medida, quantidade ou condição exata e releia.

Teste rápido

O passo “prepare o lanche das crianças” está grande demais para um algoritmo. Qual é a correção certa?

Perguntas frequentes

Nos programas de verdade a ambiguidade também aparece?: Aparece antes do programa: na conversa. Boa parte dos bugs nasce de pedidos ambíguos, como “o sistema deve avisar o cliente rapidamente”. Rapidamente é quanto? Por qual canal? Programadores experientes gastam tempo transformando pedidos vagos em regras exatas antes de escrever qualquer linha.
Como sei se o passo está pequeno o bastante?: Pergunte se o executor cumpre o passo sem decidir nada sozinho. Se cumpre, o tamanho está bom. Para o computador, os passos precisam chegar ao nível de comandos como “mostre esta mensagem” e “some estes dois números”; é o zoom máximo, e o pseudocódigo da aula 3 foi feito para escrever nesse nível.
Não é pedantismo exigir tanta precisão?: Entre humanos, seria. Nós preenchemos lacunas com bom senso o tempo todo, e a conversa flui. O computador não tem bom senso para preencher nada, então a precisão deixa de ser frescura e vira o idioma. A boa notícia: esse treino melhora até a comunicação entre pessoas.
Qual a diferença entre esta aula e a instrução clara do módulo 1?: O módulo 1 mostrou O QUE é uma instrução clara e por que a máquina exige isso. Esta aula ensina COMO produzir clareza: identificar as palavras que criam ambiguidade, trocá-las por medidas e ajustar o tamanho de cada passo. É a mesma ideia saindo do diagnóstico para a prática.
E quando o executor é uma pessoa, como numa receita de família?: Aí você pode relaxar o zoom, porque pessoas completam lacunas. Mas repare como manuais bem escritos, bulas e procedimentos de segurança usam o padrão do algoritmo: medidas exatas, uma ação por passo, ordem numerada. Quanto maior o custo do erro, menos ambiguidade se tolera.
Existe ambiguidade impossível de eliminar?: Em linguagem natural, sempre sobra alguma, e é por isso que as linguagens de programação existem: nelas, cada comando tem um significado único, sem sombra. O pseudocódigo do curso fica no meio do caminho, com português na aparência e disciplina de máquina na estrutura.

Fontes

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

← Como estudar este curso (e por que ele tem jogos) Concluir e avançar →