Erros comuns em pseudocódigo essencial: padrões de confusão e como corrigir

Por que certos pseudocódigos “não viram programa”

Um pseudocódigo essencial falha quando descreve intenções vagas em vez de passos executáveis, mistura responsabilidades ou deixa lacunas lógicas. O resultado é um texto que parece correto “para humanos”, mas não permite implementação direta sem adivinhação. A seguir estão anti-padrões recorrentes, como identificá-los (diagnóstico) e como reescrevê-los (correção padrão) com exemplos práticos.

Catálogo de erros comuns (anti-padrões) e correções

1) Passos implícitos (lacunas entre ações)

O que é: o pseudocódigo pula etapas necessárias, assumindo que o leitor “sabe” o que fazer entre duas linhas.

Diagnóstico (como identificar):

• Há saltos do tipo “pegue X” sem dizer de onde vem X.
• Uma variável aparece “do nada” (não foi obtida, calculada ou recebida).
• Uma decisão depende de informação que não foi produzida antes.

Correção padrão (como reescrever): explicite a origem dos dados e os passos intermediários, mesmo que sejam simples. Se um valor depende de uma busca, cálculo ou validação, descreva isso como etapas nomeadas.

Exemplo problemático:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

SE saldo >= valor ENTÃO    aprovar compra

Versão padronizada:

saldo <- obterSaldoDoCliente(idCliente)valor <- obterValorDaCompra(idCompra)SE saldo >= valor ENTÃO    aprovarCompra(idCompra)SENÃO    recusarCompra(idCompra)

Passo a passo prático para corrigir:

• Liste todas as variáveis usadas em condições e atribuições.
• Para cada uma, escreva uma linha dizendo como ela é obtida (leitura, parâmetro, cálculo, busca).
• Reordene o pseudocódigo para garantir que cada valor exista antes de ser usado.

2) Operações mágicas (“faça o cálculo”, “processar”, “validar”)

O que é: verbos genéricos que escondem regras, fórmulas e critérios, impedindo a implementação.

Diagnóstico (como identificar):

• Uso de palavras como “calcular”, “processar”, “validar”, “tratar”, “normalizar” sem dizer como.
• Não há critérios objetivos de sucesso/erro.
• Não há definição de entradas e saídas dessa “mágica”.

Correção padrão (como reescrever): substitua a “mágica” por uma sequência de regras explícitas ou por uma função/procedimento com contrato claro (entradas, saídas, regras e erros).

Exemplo problemático:

total <- fazer o cálculo do desconto

Versão padronizada (regras explícitas):

desconto <- 0SE clienteEhVIP = VERDADEIRO ENTÃO    desconto <- 0.10SENÃO SE valorCompra >= 200 ENTÃO    desconto <- 0.05total <- valorCompra * (1 - desconto)

Versão padronizada (encapsulando com contrato):

desconto <- calcularDesconto(clienteEhVIP, valorCompra)total <- valorCompra * (1 - desconto)

Passo a passo prático para corrigir:

• Para cada verbo genérico, pergunte: quais regras determinam o resultado?
• Escreva as regras como condições e atribuições, ou crie uma função com nome específico e descreva suas regras em comentários curtos.
• Garanta que o resultado seja determinístico (mesmas entradas, mesma saída).

3) Mistura de conceitos (UI, banco, rede e regra de negócio no mesmo bloco)

O que é: o pseudocódigo mistura responsabilidades: interação com usuário, persistência, comunicação e lógica central no mesmo fluxo, tornando difícil testar e implementar.

Diagnóstico (como identificar):

• O mesmo trecho alterna “mostrar mensagem”, “salvar no banco”, “chamar API” e “calcular regra”.
• Regras de negócio dependem diretamente de detalhes de tela, tabela, endpoint.
• Fica difícil simular manualmente sem “ambiente” (tela/banco/rede).

Correção padrão (como reescrever): separe em blocos/funções por responsabilidade: (1) obter dados, (2) validar/regra, (3) persistir/integração, (4) apresentar resultado. No pseudocódigo essencial, descreva interfaces por operações abstratas (ex.: carregarCliente, salvarPedido) e mantenha a regra de negócio independente.

Exemplo problemático:

ESCREVA "Digite o CPF"LEIA cpfcliente <- SELECT * FROM clientes WHERE cpf = cpfSE cliente.ativo ENTÃO    resposta <- HTTP POST /aprovar {cpf}    SE resposta.status = 200 ENTÃO        UPDATE clientes SET aprovado = true WHERE cpf = cpf        ESCREVA "Aprovado"

Versão padronizada (separando responsabilidades):

cpf <- lerCpfInformado()cliente <- carregarClientePorCpf(cpf)SE cliente = NULO ENTÃO    informarErro("Cliente não encontrado")    RETORNARSE cliente.ativo = FALSO ENTÃO    informarErro("Cliente inativo")    RETORNARaprovado <- solicitarAprovacaoExterna(cpf)SE aprovado = VERDADEIRO ENTÃO    marcarClienteComoAprovado(cpf)    informarSucesso("Aprovado")SENÃO    informarErro("Não aprovado")

Passo a passo prático para corrigir:

• Marque cada linha como: UI (entrada/saída), Regra, Persistência, Integração.
• Reorganize para que a Regra fique no centro e chame operações abstratas para Persistência/Integração.
• Garanta que cada operação abstrata tenha nome que descreva intenção e retorno claro.

4) Nomes genéricos e ambíguos (x, temp, dado, coisa, flag)

O que é: nomes que não indicam papel, unidade, conteúdo ou momento. Isso gera interpretações diferentes e bugs na implementação.

Diagnóstico (como identificar):

• Variáveis com nomes curtos e sem significado (ex.: x, aux, temp).
• Funções com nomes vagos (ex.: processar, tratar).
• O mesmo nome é reutilizado para coisas diferentes em pontos distintos.

Correção padrão (como reescrever): renomeie para refletir: entidade + atributo + contexto. Use nomes que indiquem booleanos (ex.: ehValido), coleções (ex.: listaDePedidos) e unidades (ex.: valorEmReais, prazoEmDias).

Exemplo problemático:

temp <- 0PARA cada item EM lista FAÇA    x <- x + item.valorSE flag ENTÃO    fazerCoisa()

Versão padronizada:

somaDosValores <- 0PARA cada item EM itensDoCarrinho FAÇA    somaDosValores <- somaDosValores + item.valorEmReaisehFreteGratis <- (somaDosValores >= 200)SE ehFreteGratis ENTÃO    aplicarFreteGratis()

Passo a passo prático para corrigir:

• Para cada nome, responda: “o que é?”, “em que unidade?”, “de onde vem?”, “para que serve?”.
• Se não der para responder olhando só o nome, renomeie.
• Evite reutilizar o mesmo identificador para significados diferentes.

5) Condições incompletas (casos não cobertos, fronteiras ignoradas)

O que é: decisões que não tratam todos os cenários relevantes (ex.: igualdade, nulos, listas vazias, limites).

Diagnóstico (como identificar):

• Há SE sem SENÃO quando existe um caminho alternativo necessário.
• Comparações ignoram fronteiras (ex.: usa > quando deveria considerar >=).
• Não há tratamento para “não encontrado”, “vazio”, “zero”, “negativo”.

Correção padrão (como reescrever): liste explicitamente os casos e trate o “caso padrão”. Quando houver fronteiras, escreva-as de forma clara. Se um caso for inválido, retorne erro cedo.

Exemplo problemático:

SE idade > 18 ENTÃO    permitirCadastro()

Versão padronizada:

SE idade < 0 ENTÃO    informarErro("Idade inválida")    RETORNARSE idade >= 18 ENTÃO    permitirCadastro()SENÃO    informarErro("Cadastro permitido apenas para maiores de idade")

Passo a passo prático para corrigir:

• Escreva os intervalos possíveis (ex.: <0, 0..17, >=18).
• Garanta que cada intervalo tenha um comportamento definido.
• Inclua um caminho padrão quando fizer sentido (erro, recusa, valor padrão).

6) Laços sem atualização (loop infinito ou progresso invisível)

O que é: laços que não alteram a condição de parada, não avançam índice, ou não consomem itens, tornando o término incerto.

Diagnóstico (como identificar):

• Em um ENQUANTO, a variável da condição nunca muda dentro do laço.
• Em processamento de lista, não há avanço de posição nem remoção/consumo.
• Há REPITA sem mudança do estado que leva ao ATÉ.

Correção padrão (como reescrever): explicite a variável de controle e atualize-a em um ponto visível. Se o laço consome itens, deixe claro como o próximo item é obtido.

Exemplo problemático:

i <- 0ENQUANTO i < tamanho(lista) FAÇA    ESCREVA lista[i]

Versão padronizada:

i <- 0ENQUANTO i < tamanho(lista) FAÇA    ESCREVA lista[i]    i <- i + 1

Exemplo problemático (condição depende de estado não alterado):

ENQUANTO senhaEhInvalida FAÇA    LEIA senha

Versão padronizada:

senhaEhInvalida <- VERDADEIROENQUANTO senhaEhInvalida FAÇA    senha <- lerSenha()    senhaEhInvalida <- (validarSenha(senha) = FALSO)

Passo a passo prático para corrigir:

• Identifique a condição de parada.
• Localize quais variáveis influenciam essa condição.
• Garanta que ao menos uma delas seja atualizada a cada iteração, ou que a coleção seja consumida.

7) Dependência da sintaxe de uma linguagem (pseudocódigo “disfarçado” de código)

O que é: o texto usa detalhes específicos (ex.: {}, ==, ++, operadores e bibliotecas de uma linguagem), reduzindo portabilidade e clareza.

Diagnóstico (como identificar):

• Uso de construções típicas de uma linguagem (ex.: for(i=0;i<n;i++)).
• Dependência de métodos/bibliotecas específicas (ex.: String.trim() sem definir o que significa).
• Operadores e precedência implícita que exigem conhecimento de linguagem.

Correção padrão (como reescrever): use palavras-chave e estruturas do padrão do curso e descreva operações como intenções claras e independentes. Se precisar de uma operação utilitária (ex.: “remover espaços”), descreva-a como função com nome explícito.

Exemplo problemático:

for(i=0;i<arr.length;i++){ if(arr[i]==x) return i; }

Versão padronizada:

i <- 0ENQUANTO i < tamanho(vetor) FAÇA    SE vetor[i] = valorProcurado ENTÃO        RETORNAR i    i <- i + 1RETORNAR -1

Passo a passo prático para corrigir:

• Substitua símbolos e atalhos por palavras e passos explícitos.
• Troque chamadas de biblioteca por funções nomeadas por intenção.
• Evite depender de “truques” de linguagem (incrementos, ternários, etc.).

Checklist rápido de revisão (use antes de considerar “pronto”)

Exercícios de revisão (reescrita para versão padronizada)

Exercício 1: “mágica” + condição incompleta

Pseudocódigo problemático:

LEIA valorSE valor > 100 ENTÃO    total <- fazer o cálculo do impostoESCREVA total

Tarefa: reescreva para (1) definir a regra do imposto, (2) tratar o caso em que valor é inválido, (3) definir o que acontece quando valor não é maior que 100.

Uma versão padronizada possível:

valor <- lerNumero()SE valor < 0 ENTÃO    informarErro("Valor inválido")    RETORNARimposto <- 0SE valor > 100 ENTÃO    imposto <- valor * 0.08total <- valor + impostoESCREVA total

Exercício 2: mistura de conceitos + passos implícitos

Pseudocódigo problemático:

ESCREVA "Login"LEIA usuario, senhaSE autenticar(usuario, senha) ENTÃO    salvar no banco o acesso    mostrar tela inicial

Tarefa: (1) explicitar o que significa autenticar (resultado booleano), (2) separar UI, regra e persistência em operações nomeadas, (3) tratar falha de autenticação.

Uma versão padronizada possível:

credenciais <- lerCredenciais()ehAutenticado <- verificarCredenciais(credenciais.usuario, credenciais.senha)SE ehAutenticado = FALSO ENTÃO    informarErro("Usuário ou senha inválidos")    RETORNARregistrarAcesso(credenciais.usuario)abrirTelaInicial()

Exercício 3: laço sem atualização + nomes genéricos

Pseudocódigo problemático:

i <- 0ENQUANTO i < n FAÇA    soma <- soma + v[i]

Tarefa: (1) corrigir o laço para avançar, (2) inicializar o acumulador, (3) renomear variáveis para intenção.

Uma versão padronizada possível:

indice <- 0somaDosValores <- 0ENQUANTO indice < quantidadeDeItens FAÇA    somaDosValores <- somaDosValores + valores[indice]    indice <- indice + 1ESCREVA somaDosValores

Exercício 4: dependência de sintaxe de linguagem + condição incompleta

Pseudocódigo problemático:

if (nota >= 7) print("A"); else if (nota >= 5) print("B");

Tarefa: reescreva no padrão essencial e inclua o caso restante (nota < 5) e validação de faixa (ex.: 0 a 10).

Uma versão padronizada possível:

nota <- lerNumero()SE nota < 0 OU nota > 10 ENTÃO    informarErro("Nota fora da faixa")    RETORNARSE nota >= 7 ENTÃO    ESCREVA "A"SENÃO SE nota >= 5 ENTÃO    ESCREVA "B"SENÃO    ESCREVA "C"

Exercício 5: passos implícitos + operação mágica em lista

Pseudocódigo problemático:

total <- 0PARA cada p EM pedidos FAÇA    total <- total + p.valorfinal <- aplicar regras de frete e cupomESCREVA final

Tarefa: (1) explicitar regras mínimas de frete e cupom, (2) deixar claro quais entradas são necessárias (ex.: cidade, cupom), (3) produzir um fluxo implementável.

Uma versão padronizada possível:

totalProdutos <- 0PARA cada pedido EM pedidos FAÇA    totalProdutos <- totalProdutos + pedido.valorEmReaiscupom <- lerCupomOpcional()cidade <- lerCidadeDeEntrega()desconto <- 0SE cupom = "DESC10" ENTÃO    desconto <- totalProdutos * 0.10frete <- 0SE cidade = "LOCAL" ENTÃO    frete <- 10SENÃO    frete <- 25valorFinal <- (totalProdutos - desconto) + freteESCREVA valorFinal