Como escrever um pseudocódigo claro

Pseudocódigo claro pode ser lido sem adivinhação

Um pseudocódigo é claro quando outra pessoa consegue identificar entradas, regras, ordem, caminhos e saídas sem completar mentalmente instruções ausentes. Ele não precisa imitar todos os detalhes de uma linguagem, mas precisa ser preciso no nível necessário para verificar o algoritmo e preparar sua implementação.

Escrever com clareza é um processo: definir o contrato, escolher o nível de detalhe, nomear os dados, organizar os blocos, testar os caminhos e revisar. A primeira versão não precisa ser definitiva.

Se o conceito ainda não estiver firme, revise o que é pseudocódigo. Nesta aula, partiremos de uma solução conhecida para melhorar a maneira de comunicá-la.

Comece pelo contrato do problema

Antes das instruções, escreva em poucas linhas:

• quais dados entram;
• quais valores são válidos;
• qual resultado deve sair;
• quais regras transformam a entrada;
• quais situações excepcionais precisam de resposta.

Considere uma taxa de entrega hipotética:

Receber a distância em quilômetros. Distâncias negativas são inválidas. Uma entrega de até 5 km custa R$ 8; acima de 5 km, custa R$ 12.

O contrato impede que “calcular a taxa” esconda decisões importantes. Já sabemos a unidade, o limite inclusivo, as duas taxas e o tratamento da entrada inválida.

Use um processo em seis etapas

1. Defina o contrato: entrada, validade, regra e saída.
2. Rascunhe o caminho principal: escreva a sequência sem buscar perfeição.
3. Substitua termos vagos: transforme “faça o cálculo” em operações observáveis.
4. Organize os blocos: deixe claro o que pertence a cada condição ou repetição.
5. Execute casos no papel: inclua situações comuns, inválidas e de fronteira.
6. Revise para outra pessoa: remova detalhes inúteis e acrescente o que ainda exige adivinhação.

Escolha o nível de detalhe pelo objetivo

Detalhe insuficiente cria ambiguidade; detalhe excessivo prende o pseudocódigo à implementação. Pergunte o que o leitor precisa decidir ou verificar. Se o formato ainda não estiver definido, compare os critérios de como representar um algoritmo.

Uma descrição de alto nível pode dizer:

valide o pedido
calcule a taxa de entrega
informe o total

Ela é adequada apenas se valide o pedido e calcule a taxa de entrega forem operações já definidas em outro lugar. Para explicar a regra dos 5 km, essa versão esconde justamente o que importa.

No outro extremo, chamadas de bibliotecas, componentes de interface, formatação específica e tratamento interno de uma linguagem geralmente pertencem ao código. O pseudocódigo deve detalhar a lógica necessária sem simular uma tecnologia que ainda não foi escolhida.

Dê nomes que revelem o papel dos dados

Compare estas atribuições:

x = d * t

valorDesconto = subtotal * percentualDesconto

A primeira pode estar correta, mas não informa o significado dos valores. A segunda permite prever a intenção da operação antes de ler o restante do algoritmo.

Prefira nomes que respondam “o que este dado representa?”:

• distanciaKm em vez de d;
• taxaEntrega em vez de x;
• quantidadeItens em vez de q;
• pedidoValido em vez de flag.

Abreviações conhecidas no domínio podem ser adequadas, mas não presuma que toda pessoa compartilha o mesmo vocabulário. Mantenha também uma única forma de nomear: se começou com distanciaKm, não alterne com dist, quilometros e distância para o mesmo dado.

Escreva ações concretas e ordenadas

Comece cada instrução com uma ação reconhecível: receba, calcule, some, compare, guarde, informe, repita ou retorne. Uma linha deve comunicar uma transformação principal.

Evite instruções como:

trate os dados corretamente
faça as verificações necessárias
calcule tudo
continue normalmente

Essas frases expressam intenção, não execução. Identifique quais dados são tratados, qual condição torna uma entrada inválida, qual fórmula é aplicada e para onde o fluxo segue.

A ordem também deve respeitar dependências. Não informe taxaEntrega antes de atribuir seu valor; não calcule com uma entrada antes de verificar se ela pertence ao domínio aceito.

Torne os blocos visíveis

Indentação — o recuo no início da linha — mostra quais instruções pertencem a uma condição ou repetição. Palavras de fechamento, como fim se, reforçam onde o bloco termina.

se pedidoAprovado
  reserve os itens
  informe "Pedido confirmado"
fim se

registre a tentativa

As duas linhas recuadas dependem de pedidoAprovado. registre a tentativa está alinhada com se, portanto ocorre depois do bloco, independentemente do resultado da condição.

Use sempre a mesma largura de recuo no documento. Em estruturas aninhadas, acrescente um nível por vez. Se houver tantos níveis que o fluxo fique difícil de acompanhar, considere dividir o problema em partes menores.

Use condições que possam ser respondidas

Uma condição clara produz verdadeiro ou falso a partir de dados definidos:

distanciaKm < 0
distanciaKm <= 5
estoqueDisponivel >= quantidadeSolicitada

Expressões como distancia aceitavel, cliente bom ou pedido grande precisam de critérios. Caso sejam regras de domínio já definidas, transforme-as em uma operação nomeada e documente sua definição em um único lugar.

Preste atenção aos limites. distanciaKm < 5 exclui o valor 5; distanciaKm <= 5 o inclui. A linguagem da regra — “até 5 km” — determina a segunda forma.

Comentários explicam decisões, não instruções óbvias

Comentários podem registrar uma restrição ou a razão de uma escolha:

// O limite de 5 km pertence à faixa de menor tarifa.
se distanciaKm <= 5
  taxaEntrega = 8
fim se

Evite comentários que apenas repetem a linha:

// Define a taxa como 8.
taxaEntrega = 8

Se o pseudocódigo depende de muitos comentários para ser compreendido, revise nomes e ações primeiro. Comentário útil preserva contexto que não está evidente na instrução; não serve para justificar ambiguidade.

Exemplo ruim: onde está a ambiguidade

Veja uma tentativa para a regra de entrega:

pegue o valor
se estiver errado, avise
senão calcule a entrega
mostre o resultado

Há pelo menos cinco problemas:

• valor não identifica distância nem unidade;
• errado não define o que torna a entrada inválida;
• calcule a entrega omite limite e tarifas;
• os blocos não mostram qual saída pertence a cada caminho;
• não sabemos se existe um resultado quando a entrada é inválida.

Reescrevendo passo a passo

Primeiro, escolha nomes e torne as condições mensuráveis. Depois, organize os caminhos e garanta uma saída para cada entrada prevista:

receba distanciaKm

se distanciaKm < 0
  informe "Distância inválida"
senão se distanciaKm <= 5
  taxaEntrega = 8
  informe taxaEntrega
senão
  taxaEntrega = 12
  informe taxaEntrega
fim se

Agora é possível responder:

• qual dado entra: distanciaKm;
• qual entrada é inválida: qualquer valor abaixo de zero;
• qual faixa inclui exatamente 5 km: a de R$ 8;
• qual taxa se aplica acima do limite: R$ 12;
• o que sai em cada caminho: mensagem ou valor da taxa.

Não é a única escrita válida. Poderíamos atribuir a taxa dentro dos caminhos e informá-la uma vez ao final, desde que o fluxo inválido não tente usar um valor inexistente. A melhor escolha é aquela que preserva a regra e permanece simples de verificar.

Teste a escrita, não apenas a ideia

Execute o pseudocódigo com casos que forcem caminhos diferentes:

Entrada	Caminho	Saída esperada
-1	inválido	Distância inválida
0	até 5 km	8
5	exatamente no limite	8
5,1	acima do limite	12

Ao fazer o teste manual, marque a primeira linha em que a execução depende de interpretação. Essa dependência revela um dado não definido, uma condição vaga ou uma ordem incompleta.

Também peça para outra pessoa explicar o algoritmo sem sua ajuda. Se a explicação divergir do contrato, descubra qual trecho permitiu a leitura alternativa e revise-o.

Checklist de clareza

Antes de considerar a versão pronta, confirme:

• a entrada, a validade e a saída estão explícitas;
• cada nome representa um único significado;
• cada ação é concreta e executável no nível descrito;
• a ordem respeita as dependências;
• toda condição possui critérios e limites claros;
• indentação e fechamentos delimitam os blocos;
• todo caminho relevante chega a uma saída ou término;
• comentários explicam razões, não repetem linhas;
• casos comuns, inválidos e de fronteira foram percorridos;
• detalhes de uma linguagem não foram adicionados sem necessidade.

Pratique com uma compra mínima

Escreva um pseudocódigo para esta regra hipotética: receba o valor de uma compra; rejeite valores negativos; conceda frete grátis para valores a partir de R$ 150; caso contrário, informe uma taxa de R$ 15.

Comece pelo contrato, escolha nomes informativos e escreva uma ação por linha. Teste com -1, 149,99, 150 e 200. Depois entregue apenas o pseudocódigo a outra pessoa e peça que ela diga a saída de cada caso.

O resultado está claro se não for necessário explicar oralmente o significado dos dados, o limite ou a relação entre os blocos.

O que você deve guardar

Pseudocódigo claro explicita o contrato, usa nomes informativos, descreve ações concretas e mostra a hierarquia dos blocos. Seu nível de detalhe depende do objetivo: suficiente para compreender e verificar a lógica, sem carregar decisões exclusivas da implementação.

Escrever, testar e revisar fazem parte do mesmo processo. No próximo conteúdo, entenda o que é um fluxograma e como representar visualmente os caminhos de um algoritmo.

Referências

• Harvard CS50 — Lecture 0: Pseudocode. Acesso em 10 set. 2026.
• Harvard CS50 — Pseudocode reference. Acesso em 10 set. 2026.
• Computer Science Teachers Association — CSTA K–12 Computer Science Standards, Revised 2017. Acesso em 10 set. 2026.
• Computer Science Teachers Association — Standards for CS Teachers. Acesso em 10 set. 2026.
• Cambridge International — Pseudocode Guide for Teachers, examination in 2026. Acesso em 10 set. 2026.
• OCR — J277/02 Computational thinking, algorithms and programming: Mark Scheme, June 2024. Acesso em 10 set. 2026.
• Google — Documentation Best Practices. Acesso em 10 set. 2026.