Fluxograma e pseudocódigo: o algoritmo antes do código

Fluxograma e pseudocódigo registram a lógica antes da sintaxe. O fluxograma mostra por onde a execução passa; o pseudocódigo nomeia cada passo numa escrita estruturada; o código traduz esse plano para regras de uma linguagem.

O exemplo central é a aprovação de crédito de uma livraria. A entrada é a renda mensal e a existência de dívida vencida. A regra aprova quando a renda é pelo menos R$ 3.000 e não há dívida. O resultado precisa existir para todos os caminhos.

Por que desenhar antes de digitar a primeira linha

Quando você começa pelo editor, precisa decidir a regra e lembrar a sintaxe ao mesmo tempo. O desenho separa as tarefas. Primeiro responda: quais dados entram, qual pergunta divide o caminho e onde cada caminho termina? Depois procure como escrever if.

Pense num mapa de metrô. As estações são operações, as bifurcações são decisões e as linhas mostram a ordem. O limite é importante: um fluxograma não transporta nada nem garante que o código corresponde ao desenho. Ele é um modelo de controle, não uma execução.

Um rascunho linear já revela o contrato:

INÍCIO
LER renda
LER possuiDividaVencida
SE renda >= 3000 E possuiDividaVencida = falso
  ESCREVER "crédito aprovado"
SENÃO
  ESCREVER "crédito negado"
FIM SE
FIM

Esse bloco é pseudocódigo, não JavaScript. Ele não promete uma saída do Node; sua função é permitir que uma pessoa revise a regra sem conhecer chaves, operadores ou métodos.

Cinco símbolos resolvem quase todo fluxo inicial

O padrão ISO 5807 descreve convenções de fluxogramas. Para começar, cinco papéis bastam: terminal para início/fim, paralelogramo para entrada/saída, retângulo para processo, losango para decisão e seta para sequência. A forma não é decoração: ela permite reconhecer a função de um nó antes de ler o texto.

O mapeamento é autoral e didático, não equivalência perfeita. Uma função JavaScript pode conter muitos símbolos; e console.log é apenas uma forma de saída. O valor da tabela é manter o mesmo papel quando a notação muda.

O losango é uma pergunta com saídas nomeadas

Um losango não diz “talvez”. Ele contém uma condição que resulta em verdadeiro ou falso. Duas setas saem dele, e cada seta precisa ter rótulo. Sem o caminho falso, você desenhou uma situação em que a execução desaparece.

Leia sem código: entram dois dados; uma pergunta separa os caminhos; cada caminho mostra uma resposta; os dois chegam ao fim. Agora você pode discutir a regra com alguém de negócio sem misturar a conversa com sintaxe.

Portugol linha a linha e as palavras do Visualg

Portugol não é uma língua universal. Visualg, Portugol Studio e materiais didáticos usam variações. No Visualg, uma forma possível é:

algoritmo "analise_credito"
var
  renda: real
  possuiDividaVencida: logico
inicio
  leia(renda)
  leia(possuiDividaVencida)
  se (renda >= 3000) e (nao possuiDividaVencida) entao
    escreval("crédito aprovado")
  senao
    escreval("crédito negado")
  fimse
fimalgoritmo

A notação adiciona tipos e palavras reconhecidas pela ferramenta. Mesmo assim, o raciocínio continua legível: ler, perguntar, escolher, escrever. Se você troca o ambiente, confira a sintaxe aceita em sua documentação, mas preserve o plano.

O mesmo algoritmo traduzido para JavaScript

Só agora entra JavaScript. A função recebe os dados; a condição traduz o losango; o retorno representa a saída lógica:

function analisarCredito(renda, possuiDividaVencida) {
  if (renda >= 3000 && !possuiDividaVencida) {
    return 'crédito aprovado';
  }
  return 'crédito negado';
}

console.log(analisarCredito(4500, false));
console.log(analisarCredito(4500, true));
console.log(analisarCredito(2500, false));

Compare linha por linha. && ocupa o papel de e; ! ocupa o papel de nao; if ocupa o papel do losango. A estrutura condicional explica os valores de borda dessa decisão.

A seta que volta transforma caminho em laço

Uma repetição tem entrada no ciclo, condição de continuação, corpo e mudança que aproxima o fim. O fluxo de três tentativas volta à decisão enquanto ainda há tentativas:

let tentativa = 1;

while (tentativa <= 3) {
  console.log(`tentativa ${tentativa}`);
  tentativa += 1;
}

console.log('fluxo encerrado');

No desenho, a seta sai do incremento e volta para o teste, não para o começo do programa. Se ela voltar depois do teste, a primeira condição não é avaliada. Se faltar incremento, a seta retorna com o mesmo estado e o laço pode nunca terminar. Veja o rastreio completo na lição de laço e contador.

Dois defeitos de desenho que viram bug

O primeiro é uma seta sem destino. Em código, costuma aparecer como uma função que não devolve resultado em certo caminho. O segundo é uma decisão sem caminho falso. Reproduza ambos numa função incompleta:

function classificarNota(nota) {
  if (nota >= 7) return 'aprovado';
}

console.log(classificarNota(8));
console.log(classificarNota(5));

Não houve exceção; isso torna o defeito traiçoeiro. O caminho de nota baixa chegou ao fim implícito e devolveu undefined. No fluxograma, desenhar a seta “não” obriga você a decidir se o resultado é “reprovado”, “recuperação” ou outro processo.

Corrija apenas o caminho ausente:

function classificarNota(nota) {
  if (nota >= 7) return 'aprovado';
  return 'recuperação';
}

console.log([8, 5].map(classificarNota));

O desenho também precisa representar entradas inválidas. Uma renda negativa não deveria cair simplesmente em “crédito negado”; ela é um dado impossível que pede outro caminho. Fluxograma ajuda justamente porque faz a omissão ocupar espaço visual.

Revise o fluxo como um contrato de caminhos

Uma revisão útil não começa perguntando se o desenho está bonito. Começa selecionando cada saída e caminhando de volta até a entrada. Se uma saída não possui caminho, ela é promessa sem implementação. Se uma entrada chega a dois resultados incompatíveis sem nova decisão, existe uma regra implícita.

Faça também a leitura para frente com casos concretos. Use renda negativa, 2.999, 3.000 e 3.001; combine cada valor com dívida verdadeira e falsa. Escreva sobre cada seta qual caso a atravessa. Esse exercício converte o desenho em cobertura: não basta existir seta “sim”, é preciso mostrar uma entrada que a percorre.

O losango deve conter uma pergunta, não uma ação. “Validar cliente” mistura processo e resultado. Prefira um retângulo “validar dados” seguido de losango “dados são válidos?”. Assim a seta falsa pode apontar para mensagem de entrada inválida, enquanto a verdadeira segue para análise de crédito.

Transforme cada símbolo sem perder o papel

Na tradução, preserve responsabilidades. Uma entrada do fluxograma pode virar parâmetro, leitura do terminal ou dado de formulário; escolha uma fronteira e documente o formato. Um processo pode virar expressão ou função. Uma decisão vira condição booleana, e uma saída lógica pode virar retorno antes de ser exibida.

Não faça tradução por formato visual. Dois retângulos consecutivos não exigem duas funções, e um losango não exige um else se o caminho falso simplesmente continua. O objetivo é preservar o comportamento descrito, não reproduzir o desenho como cerimônia.

Uma técnica prática é numerar os nós e anotar o número como comentário temporário ao lado da primeira versão do código. Execute um caso por caminho, depois remova os comentários quando nomes e estrutura já tornarem a correspondência legível. Se um nó não encontra lugar, talvez o desenho carregue etapa desnecessária ou o código tenha pulado uma regra.

Fluxos com repetição precisam provar progresso

Toda seta que volta merece uma variável de progresso. Pode ser contador que aumenta, tamanho de fila que diminui ou estado que muda após entrada válida. Sem progresso observável, a volta depende de sorte ou evento não representado.

Para revisar um laço desenhado, anote o estado na chegada ao losango nas três primeiras voltas e na última. Confirme que o corpo altera ao menos um dado usado pela condição. Depois considere interrupções antecipadas: encontrar o item pode levar direto à saída, enquanto esgotar a coleção segue pelo caminho “não encontrado”.

Fluxo de tentativa de senha, por exemplo, precisa separar “senha correta” de “ainda há tentativas”. Se juntar as duas perguntas num losango complexo, a tabela verdade deve acompanhar o desenho. Separá-las em decisões sequenciais costuma revelar melhor qual mensagem aparece em cada caso.

Pseudocódigo também recebe revisão técnica

Escrever em português não autoriza frases vagas. Use um verbo por passo, declare dados modificados e mantenha blocos de decisão fechados. SOMA recebe SOMA mais NOTA é rastreável; “atualizar total” esconde operação e variável.

Evite copiar sintaxe de uma linguagem e apenas traduzir palavras. Pseudocódigo deve diminuir carga de sinais, não criar um JavaScript em português. Ao mesmo tempo, preserve estruturas que serão necessárias: condição, repetição, chamada e retorno. Esse equilíbrio deixa o plano legível e traduzível.

Peça a uma pessoa para fazer um teste de mesa usando somente o pseudocódigo. Se ela precisa abrir a implementação para descobrir valor inicial ou condição de parada, o plano ainda está incompleto. Se consegue obter a saída, a tradução vira uma tarefa menor e verificável.

Guarde a versão revisada junto do caso usado na simulação. Quando a regra mudar, atualize primeiro desenho e pseudocódigo, escolha um caso capaz de distinguir as versões e só então altere a implementação. Essa ordem transforma o modelo em instrumento de decisão, não em documentação atrasada. Um diagrama que não acompanha mudança crítica deve ser removido ou corrigido; informação antiga transmite confiança falsa.

Quando parar de desenhar e abrir o editor

Pare quando você consegue apontar, sem hesitar, a entrada, cada transformação, todos os caminhos de decisão, a condição de saída de cada laço e o resultado final. Para uma função de três linhas, um pseudocódigo curto pode bastar. Para regras com muitas faixas ou voltas aninhadas, o desenho paga o tempo investido.

Faça este teste de cobertura antes de traduzir:

const caminhos = ['renda inválida', 'aprovado', 'negado'];
const resultadosDefinidos = { 'renda inválida': true, aprovado: true, negado: true };

console.log(caminhos.every((caminho) => resultadosDefinidos[caminho]));

Seu próximo passo é desenhar uma regra de frete com três faixas, rotular todas as setas e escrever o pseudocódigo antes do JavaScript. Confira as bordas com um teste de mesa, mantenha o mapa do guia de lógica ao lado e use a trilha completa para avançar sem pular pré-requisitos.