A técnica do console debugging com escreval — por que todo programador precisa aprender a interrogar o próprio código antes de tentar corrigi-lo.
Existe um momento específico no aprendizado de programação que todo iniciante enfrenta: o programa roda, a tela pisca, e nada acontece. O cursor fica parado. A máquina não responde. O processo precisa ser encerrado manualmente. O aluno olha para o código e não encontra o erro — porque o código parece correto.
O que aconteceu é um loop infinito. E a razão pela qual ele é tão difícil de identificar é que o código não está errado sintaticamente — ele está errado logicamente. A estrutura é válida. A variável existe. A condição faz sentido. O que falta é uma única linha: a que atualiza a variável de controle a cada iteração.
Alunos conseguem escrever a estrutura do while corretamente mas produzem programas que travam. O motivo quase sempre é idêntico: a variável que controla a condição não é modificada dentro do bloco. Sem uma técnica sistemática de diagnóstico, o aluno tenta corrigir o código por tentativa e erro — o que reforça uma abordagem assistemática que escala mal em projetos reais.
Por que o loop infinito é o bug mais formativo do ensino de laços?
Na escola pública, com turmas grandes e tempo de aula disputado, o loop infinito costuma gerar dois comportamentos opostos: o aluno que trava junto com o programa e espera o professor resolver, e o aluno que fecha tudo e começa do zero sem entender o que deu errado. Nenhum dos dois aprendeu a depurar.
A aula 3 da série usa exatamente esse bug como objeto de estudo. O aluno não aprende sobre loop infinito de forma abstrata — ele produz um, observa o comportamento, formula hipóteses sobre a causa e aplica uma técnica de diagnóstico para confirmar o que está acontecendo antes de corrigir. Esse é o ciclo intelectual correto: observar, diagnosticar, corrigir, verificar.
Um loop infinito ocorre quando a condição de parada de um laço enquanto nunca se torna falsa porque a variável de controle não é atualizada dentro do bloco, fazendo o programa repetir o mesmo bloco de código indefinidamente até ser interrompido externamente.
Quais são as causas e como distingui-las?
| Causa | O que acontece no código | Comportamento observado | Correção |
|---|---|---|---|
| Ausência de atualização | A variável de controle não é modificada dentro do bloco | Programa trava, mesma saída repetida | Adicionar linha de atualização (contador := contador - 1) |
| Atualização no sentido errado | A variável é modificada, mas se afasta da condição de parada | Programa trava, valores crescendo indefinidamente | Inverter a operação de atualização |
| Condição jamais falsa | A expressão booleana é sempre verdadeira por construção | Programa trava imediatamente | Revisar a expressão da condição |
| Atualização fora do bloco | A linha de atualização existe, mas está depois do fimenquanto | Programa trava, atualização nunca executada | Mover a linha para dentro do bloco |
Como funciona a técnica do console debugging com escreval?
A técnica mais simples e acessível de depuração para iniciantes é inserir temporariamente uma linha de saída dentro do bloco do laço que exibe o estado da variável de controle a cada iteração. Em ambientes profissionais, isso é feito com ferramentas de debugger integradas à IDE. Em VisualG, o equivalente direto é o escreval usado como instrumento de inspeção.
A lógica é simples: se a variável de controle não está mudando, o escreval mostrará o mesmo valor repetido na tela. Se está mudando no sentido errado, os valores exibidos revelarão a progressão incorreta. Em ambos os casos, o diagnóstico precede a correção — o que é um princípio fundamental de qualquer engenharia de software.
- Execute e observe: rode o código com bug e documente o comportamento exato. O programa trava? Repete sempre a mesma saída? Esse é o sintoma — não pule para a correção sem ter o sintoma claro.
- Formule hipóteses: antes de depurar, escreva no papel o que você acha que está acontecendo. Qual variável suspeita de estar estática? Em que ponto do código isso deveria mudar?
- Insira a linha de debug: adicione
escreval("[DEBUG] variavel = ", variavel)imediatamente antes do final do bloco. Execute novamente e observe os valores impressos. A variável está mudando? No sentido correto? - Corrija e verifique: com o diagnóstico confirmado, adicione ou corrija a linha de atualização. Execute novamente. Remova a linha de debug após confirmar o funcionamento correto.
Templates copiáveis — do bug à versão corrigida
algoritmo "LoopInfinito" Var contador: inteiro Inicio contador := 5 enquanto contador > 0 faca escreval("Contando: ", contador) // BUG: variável contador nunca é decrementada // a condição contador > 0 é sempre verdadeira fimenquanto escreval("Pronto!") Fimalgoritmo
algoritmo "LoopInfinitoDebug" Var contador: inteiro Inicio contador := 5 enquanto contador > 0 faca escreval("Contando: ", contador) [DEBUG] linha temporária de inspeção — remover após corrigir escreval("[DEBUG] contador = ", contador, " | contador > 0 = ", contador > 0) fimenquanto Fimalgoritmo // Resultado observado: contador = 5 | contador > 0 = Verdadeiro // contador = 5 | contador > 0 = Verdadeiro ← valor estático = bug confirmado
algoritmo "ContagemRegressiva" Var contador: inteiro Inicio contador := 5 enquanto contador > 0 faca escreval("Contando: ", contador) contador := contador - 1 ← atualização da condição — correção do bug fimenquanto escreval("Pronto!") Fimalgoritmo // Saída: Contando: 5 / Contando: 4 / Contando: 3 / Contando: 2 / Contando: 1 / Pronto!
# Python — mesmo padrão, sintaxe diferente contador = 5 while contador > 0: print(f"Contando: {contador}") contador -= 1 # atualização — equivalente a contador := contador - 1 print("Pronto!") # Técnica de debug equivalente (remover após corrigir): # print(f"[DEBUG] contador = {contador} | condição = {contador > 0}")
O detetive de bugs em sala: investigação colaborativa em grupos
A atividade prática da Aula 3 coloca grupos de até cinco alunos diante de um código com bug deliberado. A estrutura é investigativa: antes de qualquer correção, o grupo precisa executar o código com bug, observar o comportamento e formular por escrito uma hipótese sobre a causa.
A introdução da linha de debug não é fornecida como solução — é apresentada como uma técnica de investigação. O grupo insere o escreval de inspeção, executa novamente e discute o que os valores exibidos revelam sobre o estado interno do programa. Somente depois do diagnóstico confirmado a correção é implementada.
Esse fluxo — observar, hipotetizar, diagnosticar, corrigir, verificar — é o mesmo fluxo de qualquer engenheiro de software em depuração profissional. A diferença de escala é enorme, mas a lógica de investigação é idêntica. Ao ensinar isso com VisualG em uma aula de 45 minutos na escola pública, estamos ensinando muito mais do que um comando: estamos ensinando uma postura técnica perante o erro.
Um loop infinito é causado pela ausência de atualização da variável de controle dentro do bloco do while. A técnica de diagnóstico é inserir temporariamente um escreval que exibe o valor da variável a cada iteração — se o valor não muda, o bug está confirmado. A correção é sempre a mesma: adicionar a linha de atualização dentro do bloco, antes do fimenquanto.
Perguntas frequentes sobre loops infinitos e depuração
O que é um loop infinito e como reconhecê-lo em execução?
Um loop infinito ocorre quando a condição de parada de um laço while nunca se torna falsa. Em execução, o comportamento típico é o programa travar sem encerrar, às vezes exibindo repetidamente a mesma saída na tela, às vezes simplesmente não respondendo. Em VisualG, o programa precisa ser encerrado manualmente com o botão de parar a execução.
Por que o escreval funciona como ferramenta de debug?
O escreval exibe o estado de uma variável em um momento específico da execução. Inserido dentro do bloco do laço, ele revela o valor da variável de controle a cada iteração — tornando visível algo que normalmente é invisível durante a execução. Se o valor não muda entre iterações, o bug está localizado: a variável não está sendo atualizada. Em IDEs profissionais, ferramentas de debugger fazem o mesmo sem precisar escrever código adicional, mas a lógica de inspeção é idêntica.
Como prevenir loops infinitos antes de executar o código?
Antes de executar, verifique mentalmente três coisas: a variável de controle foi inicializada antes do laço? Existe uma instrução dentro do bloco que modifica essa variável? A modificação aproxima a variável da condição de parada? Se a resposta a qualquer uma dessas perguntas for negativa, o laço tem risco de ser infinito. Essa verificação em três etapas é mais eficiente do que testar por execução.
A linha de debug precisa ser removida após a correção?
Sim. Linhas de debug são instrumentos de diagnóstico, não parte da lógica do programa. Em produção, exibir mensagens de debug na saída do usuário é um erro de qualidade. O fluxo correto é: inserir a linha de debug, diagnosticar, corrigir e então remover a linha de debug antes de considerar o programa concluído. Em alguns projetos, as linhas de debug são deixadas comentadas para uso futuro.
Existe diferença entre depurar com escreval e usar um debugger de IDE?
A diferença é de ferramenta, não de lógica. O escreval exige que o programador insira código temporário para tornar o estado visível. Um debugger de IDE permite inspecionar variáveis sem modificar o código, pausando a execução em qualquer linha (breakpoint) e avançando passo a passo. Quem entende a lógica do escreval como ferramenta de inspeção entende o debugger — a abstração é a mesma, o nível de automação é diferente.
Sequência completa de aulas no blog
While, contadores, sentinela, depuração — toda a série documentada com artigos, slides e códigos do laboratório de educação digital.
professorcomia.com.brA virada: tratar o erro como dado, não como fracasso
O loop infinito que trava o programa não é uma falha do aluno — é uma informação. Ele informa que a variável de controle não está sendo atualizada. A diferença entre o aluno que fecha o programa e começa do zero e o aluno que insere um escreval de inspeção para entender o que está acontecendo é uma diferença de mentalidade: o segundo trata o erro como dado a ser analisado, não como obstáculo a ser evitado.
Essa é a competência que vai além do while, além do VisualG, além de qualquer linguagem específica. É a postura do engenheiro diante do sistema que não se comporta como esperado: observar, diagnosticar, corrigir, verificar. Ensinar isso na aula 3 de uma série sobre estruturas de repetição em uma escola pública é, ao mesmo tempo, ensinar lógica de programação e ensinar método científico aplicado.