Por que um programa compila e dá resultado errado?

Erros de sintaxe impedem a tradução quando quebram uma exigência formal, como o ponto e vírgula obrigatório. Incompatibilidades de tipo são problemas de significado que o tradutor pode detectar. Erros de lógica permanecem possíveis com sintaxe válida e aparecem como resultados incorretos.^[1]

Use essa comparação como roteiro de triagem. Se o ambiente aponta a falta de um sinal obrigatório, comece pela sintaxe.^[1] Se ele informa incompatibilidade entre um valor e o tipo declarado, examine o significado daquele uso.^[1] Quando a compilação termina e a resposta continua errada, volte ao algoritmo, a sequência de passos escolhida para resolver o problema. Uma falha nesse raciocínio pode produzir resultado incorreto sem violar a sintaxe.^[1]

O compilador pode confirmar que os comandos têm forma válida e ainda desconhecer se eles representam a intenção do problema. A lógica escolhida fica fora dessa garantia quando seus comandos são aceitos. Por isso, uma operação inadequada pode gerar resposta errada sem bloquear a tradução.^[1]

Imagine um sistema escolar que precisa calcular um resultado a partir das notas registradas. O código usa comandos aceitos e valores compatíveis, mas combina esses valores de modo diferente da regra pretendida. A tradução pode terminar, enquanto a resposta exibida permanece incorreta. Esse exemplo representa a distinção descrita pela fonte: a sintaxe válida permite traduzir, mas uma falha de raciocínio no algoritmo ainda altera o resultado.^[1]

A diferença lembra uma receita escrita em português correto, mas com uma etapa trocada. A escrita pode estar compreensível, enquanto o preparo produz algo diferente do esperado. No programa, a compilação examina regras que o tradutor consegue verificar; a adequação do raciocínio exige outra análise.^[1] O limite desta explicação aparece nas linguagens e ferramentas específicas: as fontes distinguem erros detectáveis e falhas lógicas, mas não fornecem um catálogo de comportamentos para cada compilador.^[1]

Depois da compilação, confronte o comportamento com resultados esperados definidos antes da execução e cubra limites e exceções. A verificação por casos procura revelar falhas de raciocínio que a tradução não rejeita. Esse trabalho deve incluir condições de contorno e casos extremos.^{[1, 2]}

1. Leia a mensagem: confirme se ainda existe um impedimento de sintaxe indicado pelo ambiente.^[1]
2. Confira os tipos: procure valores incompatíveis com as declarações usadas pelo programa.^[1]
3. Explicite o esperado: registre qual resposta o raciocínio deveria produzir para a entrada analisada.^[1]
4. Compare o cálculo: localize a etapa em que o resultado obtido se afasta do resultado esperado.^[1]
5. Cubra os limites: inclua condições de contorno, casos extremos e exceções capazes de invalidar a solução.^[2]

Esse roteiro separa a pergunta sobre tradução da pergunta sobre correção. O sucesso da compilação permite avançar, mas não elimina a necessidade de testar a solução contra resultados esperados.^[1] Segundo Robert C. Martin, a correção de um algoritmo não deve ser presumida por intuição; limites, exceções e casos extremos precisam ser identificados e cobertos por testes.^[2] Se uma entrada revela resposta divergente, revise o passo do raciocínio que produziu essa diferença, mesmo que nenhuma mensagem do compilador apareça.^[1]

Casos extremos pressionam limites e exceções capazes de invalidar uma solução que parecia correta. A compilação bem-sucedida continua igual, pois o problema está na adequação do raciocínio às entradas testadas. Sem cobertura desses casos, a confiança depende de intuição insuficiente.^[2]

Uma solução pode funcionar nos exemplos usados durante a escrita e falhar quando encontra uma condição de contorno que ficou fora da verificação.^[2] Por isso, um resultado correto em uma execução isolada oferece evidência estreita. A obra Clean Code recomenda identificar e testar condições de contorno, casos extremos e exceções, pois esses elementos podem invalidar uma solução aparentemente correta.^[2] O que você faz com isso é concreto: mantenha a compilação como uma etapa de controle e reserve a avaliação do resultado para casos escolhidos de modo consciente.^{[1, 2]}

Esta dúvida permanece vinculada ao conteúdo relacionado do curso, enquanto o foco aqui fica restrito ao limite da compilação como evidência de correção. Para uma questão de escopo mais amplo, Computação é mais do que programar? Entenda pode ser mantido como leitura separada. A comparação Licenciatura em Computação ou ADS: diferenças também pertence a outra dúvida. O ponto fraco das fontes usadas neste artigo é deliberado: elas sustentam a separação entre tradução, tipos e raciocínio, mas não especificam técnicas de teste para cada linguagem.^{[1, 2]}

Se o programa compilou, o código está correto?

Não necessariamente. A compilação mostra que o tradutor aceitou a construção e não encontrou certos erros que consegue detectar. Ela não comprova que o raciocínio escolhido representa corretamente o problema. Uma falha lógica pode permanecer em código com sintaxe válida e produzir uma resposta incorreta.^[1]

Todo erro de tipo impede a compilação?

A evidência fornecida não permite afirmar que todo erro de tipo será detectado em qualquer linguagem. Ela estabelece um limite mais estreito: alguns erros semânticos, como fornecer um valor incompatível com o tipo declarado, podem ser identificados pelo tradutor. O comportamento específico depende das regras que não estão detalhadas nas fontes.^[1]

Como os casos extremos ajudam a encontrar erros de lógica?

Casos extremos submetem a solução a limites e exceções que podem ter ficado fora dos exemplos iniciais. Se um desses casos produz resposta divergente, ele revela que o raciocínio não cobre toda a situação pretendida. A recomendação sustentada pela fonte é identificar essas condições e incluí-las nos testes.^[2]