Como corrigir exercícios de programação online

Corrigir exercício de programação online é ler o código do aluno com três perguntas na cabeça — funciona? dá para ler? usou o conceito da aula? — e responder com uma devolutiva escrita que aponte o ponto exato do problema, sem entregar a solução pronta. Quando ainda não está bom, o exercício volta para o aluno refazer em vez de virar nota baixa. Corrigir assim demora mais na primeira volta e economiza semanas depois, porque o erro é resolvido na hora em que ele ainda faz sentido para quem escreveu o código.

Este guia é para professor de curso livre, escola técnica ou projeto de formação que corrige código de gente que está começando. Ele trata de critério, de texto de devolutiva e de como não afundar em pilha de correção.

Por que corrigir código é diferente de corrigir prova

Numa prova de história, a resposta está certa ou errada, e a correção termina ali. Em programação, quase nada é binário. Um código pode dar a saída certa e estar completamente errado — o aluno acertou por acaso, com um valor fixo no lugar da conta. Outro pode dar a saída errada e estar quase inteiro certo, faltando um sinal de maior ou igual.

Há três diferenças práticas que mudam o jeito de corrigir:

Existe mais de uma resposta certa. Se o enunciado pedia somar dez números, tanto faz se o aluno usou while ou for. Corrigir "não foi do jeito que eu fiz" é o erro mais comum de professor iniciante.
O código roda. Você pode executar e ver. Não corrija de cabeça: rodar leva dez segundos e evita apontar erro que não existe.
O erro tem causa, não só sintoma. "Deu resultado errado" não é diagnóstico. A causa costuma ser uma de poucas coisas: precedência de operador, condição invertida, contador que começa no lugar errado, variável escrita com nome diferente do que foi criada.

Três perguntas que dão conta de quase toda correção

Você não precisa de uma rubrica de vinte linhas. Para exercício de iniciante, três critérios resolvem, nesta ordem:

Funciona? Roda sem erro e responde o que o enunciado pediu, inclusive nos casos de borda óbvios (nota exatamente 6, lista vazia, valor zero).
Dá para ler? Nomes de variável dizem o que guardam ($precoTotal, não $x2), a indentação está de pé, não sobrou código morto do rascunho.
Usou o conceito da aula? Se a aula era sobre laço de repetição e o aluno copiou e colou a mesma linha dez vezes, o exercício não cumpriu a função dele — mesmo funcionando.

A ordem importa. Não comente indentação de um código que ainda nem roda: o aluno não tem espaço mental para duas correções ao mesmo tempo. Aponte o que impede de funcionar, devolva, e trate legibilidade na volta seguinte.

Devolutiva ruim e devolutiva boa, no mesmo código

Vamos a um caso real de turma iniciante. O enunciado: calcular a média de duas notas e dizer se o aluno foi aprovado (média maior ou igual a 6). O que chegou:

<?php
$nota1 = 4;
$nota2 = 6;
$media = $nota1 + $nota2 / 2;

if ($media >= 6) {
    echo "Aprovado";
} else {
    echo "Recuperação";
}

Saída: Aprovado. E é aí que mora o problema — a média real é 5, o aluno deveria estar em recuperação. O PHP divide antes de somar, então a conta que rodou foi 4 + 3, dando 7. O código não quebra, não dá erro na tela e entrega uma resposta errada com cara de certa.

Uma devolutiva ruim para esse código é qualquer uma destas:

"Errado, refaça." — não diz onde nem por quê.
"Faltou parênteses na linha 4." — corrige o sintoma e não ensina nada; na próxima o aluno erra igual.
"Troque por $media = ($nota1 + $nota2) / 2;" — entrega a solução; o aluno copia, cola, entrega e segue sem entender.

Uma devolutiva boa faz três coisas: mostra o efeito, dá a pista da causa e devolve a tarefa para o aluno. Por exemplo:

Seu código roda e a lógica do if está certinha. Só que ele imprimiu "Aprovado" para notas 4 e 6, e a média dessas duas é 5. Rode de novo colocando um echo $media; antes do if e veja qual valor aparece. Depois pense na ordem em que o PHP resolve a conta: ele faz a divisão antes da soma. Ajusta e me manda de novo.

Ela cabe em quatro linhas, leva menos de um minuto para escrever e ensina duas coisas: precedência de operadores e o hábito de imprimir valor intermediário para investigar. O aluno volta com o código consertado por ele mesmo, que é a única forma que gruda.

Três regras para o texto da devolutiva: fale do código, nunca da pessoa ("o código não trata o caso de nota zero", não "você não pensou"); comece pelo que está certo, porque quem está começando lê correção com o coração acelerado; e termine com uma ação clara, do tipo "ajusta essa parte e reenvia".

Devolver para refazer é o recurso mais subutilizado

Na cultura de prova, entregar é o fim. Em programação, entregar deveria ser o meio. Um exercício que volta com apontamento e é reenviado gera duas ou três voltas de aprendizado no mesmo enunciado — e uma segunda entrega quase sempre vem muito melhor que a primeira, porque o aluno já viu o próprio erro de fora.

Para isso funcionar, combine com a turma desde o primeiro dia: voltar não é reprovar. É o normal. Programador profissional tem código revisado e devolvido toda semana. Quando o professor trata o refazer como parte do processo, o aluno para de esconder que travou.

Ferramentas de aula genéricas costumam não ter esse passo — dá para comentar e dar nota, mas reabrir a entrega é manual. É por isso que o "devolver" aparece como requisito no guia sobre o que uma plataforma para professor de programação precisa ter. No Aulab, aprovar ou devolver para refazer são os dois botões do fim da correção, e o histórico das tentativas fica junto do exercício, então dá para ver a evolução da primeira para a última versão.

Como corrigir sem virar o gargalo da turma

Trinta alunos, dois exercícios por semana: são sessenta correções. Sem método, isso ocupa o fim de semana inteiro e a devolutiva chega tarde demais para servir. O que funciona na prática:

Corrija em lote, por exercício, não por aluno. Ver as trinta respostas do mesmo enunciado seguidas faz você reconhecer padrões em cinco minutos. Aí a correção da vigésima leva quinze segundos.
Anote os erros repetidos. Se doze pessoas erraram a mesma coisa, o problema não é delas: é da aula. Isso vira os primeiros dez minutos do próximo encontro, e você economiza doze devolutivas longas.
Tenha meia dúzia de textos-base. Devolutivas para os erros clássicos — precedência, condição invertida, contador começando errado — escritas uma vez e adaptadas em cada caso. Adaptar é obrigatório: devolutiva genérica o aluno percebe na hora.
Priorize quem travou. Corrija primeiro os que estão para trás e os que já refizeram. Quem vai bem espera dois dias sem prejuízo.
Corra o olho na saída antes de ler linha por linha. Rode o código, veja o resultado, só então mergulhe. Isso encurta metade das correções.
Não corrija tudo. Exercício de fixação pode ser conferido em voz alta na aula seguinte. Guarde a correção individual escrita para o que vale.

Um detalhe que ajuda mais do que parece: usar variações do mesmo exercício, com números ou contexto diferentes por aluno. Some o efeito colateral de reduzir cópia e o efeito principal de deixar você comparar raciocínios em vez de comparar respostas iguais. Se precisar de banco de enunciados para começar, o guia de exercícios de lógica de programação com resposta traz um conjunto pronto por nível.

Perguntas frequentes

Preciso dar nota para todo exercício de programação?

Não. Na maior parte dos cursos livres, aprovado ou devolvido para refazer basta e informa mais que uma nota de zero a dez. Se a instituição exige nota, aplique-a no fechamento da etapa, considerando a entrega já refeita — o que importa é onde o aluno chegou, não onde ele começou.

Como corrigir código sem entregar a resposta pronta?

Aponte o efeito e não a linha: mostre um caso em que o programa dá resposta errada e peça para o aluno investigar, sugerindo uma pista concreta como imprimir um valor intermediário. Só entregue a correção literal quando o aluno já tentou duas vezes e continua parado, senão a devolutiva vira transcrição.

Quanto tempo devo levar para devolver uma correção?

O ideal é antes da aula seguinte, para o aluno reencontrar o próprio raciocínio ainda quente. Devolutiva que chega duas semanas depois é praticamente inútil: o aluno já esqueceu o que estava tentando fazer e lê o comentário como se fosse sobre o código de outra pessoa.

Vale a pena usar correção automática?

Como apoio, sim; como pilar, não. Verificar automaticamente se a saída bate ajuda em exercício de sintaxe, mas em turma iniciante o código costuma quase funcionar, e o valor pedagógico está exatamente em explicar por que aquele quase não fecha. Máquina dizendo "errado" para quem está começando produz desistência, não aprendizado.

E quando o aluno claramente copiou o código de outro?

Trate como conversa, não como flagrante. Peça para ele explicar em voz alta o que cada trecho faz; em trinta segundos fica claro se entendeu. Usar variações do mesmo enunciado entre alunos reduz muito a cópia sem precisar de vigilância, porque a resposta do colega simplesmente não serve.