Existe uma estratégia melhor do que confiar no compilador para detectar erros?


8

Venho programando em C e C ++ há algum tempo, embora eu diria que estou longe de ser um especialista. Há algum tempo, venho usando várias estratégias para desenvolver meu código, como testes de unidade, design orientado a testes, revisões de código e assim por diante.

Quando escrevi meus primeiros programas no BASIC, digitei longos blocos antes de descobrir que eles não funcionariam e eram um pesadelo para depuração. Então eu aprendi a escrever um pouco e testá-lo.

Hoje em dia, muitas vezes me pego escrevendo repetidamente um pequeno pedaço de código e depois usando o compilador para encontrar todos os erros. Tudo bem se detectar um erro de digitação, mas quando você começar a ajustar os tipos de parâmetros, etc., apenas para compilá-lo, você pode estragar o design. Parece também que o compilador está entrando no processo de design quando deve ser usado apenas para verificar a sintaxe.

Há um perigo aqui de confiança excessiva no compilador para melhorar meus programas. Existem estratégias melhores que essa?

Lembro-me vagamente há algum tempo de um artigo sobre uma empresa que desenvolvia um tipo de compilador C, em que um arquivo de cabeçalho extra também especificava os protótipos. A idéia era que as inconsistências na definição da API seriam mais fáceis de detectar se você tivesse que defini-la duas vezes de maneiras diferentes.


Confie no programador para detectar erros ... através da análise, compreensão, teste e compilação.
dietbuddha

Respostas:


13

Não ajuste as coisas para fazê-lo compilar. Ajuste as coisas para que estejam corretas . Se ele foi "projetado" para que os tipos de parâmetro não correspondessem, o designer não tem idéia do que está fazendo.

Se você não quiser confiar no compilador, melhore o seu conhecimento do idioma. Estude a estrutura de definições e declarações e verifique o que você escreve para erros antes de compilar. E use revisões de código.

Essa ideia de protótipos extras parece ruim. Se você o projetou errado uma vez, o que impede o segundo design incorreto? E usando diferentes formatos / paradigmas / etc para a mesma coisa, é provável que você confunda as pessoas. Eu garantiria que todos entendessem o formato principal, para que você possa se concentrar em obter o design correto da primeira vez, em vez de dobrar o trabalho de design para detectar erros. Como todo o resto, os designs devem ser refatorados, mas não acho que fazê-lo duas vezes para começar faça muito sentido.


Acho que o designer (eu) não lembrava o parâmetro da outra função corretamente, provavelmente porque estou pensando em uma versão anterior do design.
koan

O segundo arquivo de cabeçalho não foi escrito no padrão C e acho que era da forma de protótipos de nível superior. A idéia era que, se suas duas definições diferentes definissem a mesma coisa, é mais provável que seu design estivesse correto. Não eram dois arquivos de cabeçalho C padrão, mas com "digitação" diferente.
koan

Mas isso foi na fase de implementação, certo? De qualquer forma, basta alterá-lo para seguir o design ou alterar o design para que esteja correto ... não apenas faça o compilador feliz;). Atualizarei minha resposta para refletir sua explicação sobre os protótipos.
Matthew Leia

Entendi seu ponto de vista e acho que é uma boa resposta, mas em que estágio você diz "Uau, preciso interromper toda a implementação e voltar a obter o design correto", porque "apenas alterar o design" também pode ser feito rapidamente rapidamente, completamente ou muito bem ...
koan

Essa é uma pergunta muito difícil de responder. Eu acho que é mais um sentimento baseado na experiência do que qualquer outra coisa, exceto quando você encontra o raro "uau, nós entendemos completamente esse problema, precisamos refazer o design".
Matthew Leia

4

Honestamente, acredito que seu objetivo SEMPRE seja escrever um programa que seja compilado pela primeira vez. Sei que isso é difícil e provavelmente não acontecerá com frequência, mas ainda deve ser seu objetivo. Pense no software como uma peça de hardware. Acredite que é irrealisticamente caro recompilar seu código (como refazer a fabricação de uma placa). Um complier não é um depurador e não deve ser tratado como tal.


+1 para "o compilador não é um depurador"
Joris Meys

Interessante. Eu sempre me senti muito mais confortável se encontrasse um erro, porque inevitavelmente eles existem no meu código, é que ainda não os encontrei. Minha pergunta não é tanto sobre depuração; Estou procurando estratégias para projetar ou escrever código que sejam mais eficazes na produção de um bom código. Por exemplo, se o seu compilador fornecer mais de X mensagens de erro não triviais, você deve parar e repensar o design; ou alguma coisa.
quer

Acho que sua melhor aposta em aprender a escrever um bom código é ler um livro sobre. Eu recomendo o código completo. É o melhor livro que li pessoalmente sobre software em geral.
Pemdas

Eu sinto que você está tentando anular o problema por não tê-lo em primeiro lugar. Isso não é ruim, mas no final haverá problemas que surgirão durante a compilação; afinal, ninguém é perfeito.
koan

1
Enquanto um compilador não é um depurador - uma das minhas maneiras preferidas de fazer certas refatorações é torná-lo tal que o código antigo não seja compilado (renomeando talvez). Torna mais fácil encontrar coisas que foram perdidas.
Sdg

3

O compilador não consegue encontrar todos os erros, então não faz sentido fingir que pode. Tudo o que pode encontrar são os erros e erros de sintaxe. É bom o suficiente para que eu faça essa parte do trabalho (embora hoje em dia o ambiente capture 99% deles antes de você compilar), mas eu sei perfeitamente que não são todos esses erros.

A única vez em que confio nesse tipo de informação para me dizer o que escrever é quando recebo coisas do tipo me dizendo que não é possível converter automaticamente um duplo em um float - se o local para onde você estiver enviando os dados espera flutuação (e como o que estou fazendo atualmente é brincar com a biblioteca XNA que faz exatamente isso) e a fonte retorna o dobro (como é o caso da biblioteca matemática C #), então você simplesmente precisa converter.


1

O compilador é uma ferramenta. Como todas as ferramentas, elas podem ser abusadas.

Quando você está começando pela primeira vez com um idioma, não há nada de errado em usar o compilador às cegas para testar seu programa. É assim que o aprendizado funciona, adivinhe e verifique. No entanto, isso não significa que você deve continuar a codificar dessa maneira.

É do seu interesse entender o idioma suficientemente bem para poder compilar seu programa em sua cabeça. Então você gastará menos tempo aguardando a conclusão do compilador.

Eu digo que provavelmente é melhor que o programa esteja sempre dentro de algumas linhas / blocos de código para ser compilável.


0

A maioria dos IDE modernos tem muitos problemas de compilador e acho que também me tornei bastante dependente disso.

Talvez volte para arquivos de texto e compiladores de linha de comando?


Eu não uso um IDE! Talvez eu devesse começar? Eu sempre pensei que deveria, mas nunca encontrei uma que fosse feliz.
koan
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.