Pergunta

Quanto tempo você deve manter o código antigo comentada em sua base de código? Os empreiteiros continuar a manter o código antigo na base de código, transformando-a comentários. Isso é realmente frustrante e eu quero que eles apenas remover o código antigo, em vez de comentar isso.

Existe uma razão válida para manter o código antigo na base de código como comentários? Eu estou usando o controle de versão de Visual Sourcesafe

Foi útil?

Solução

Se você usar algo como SVN ou CVS, não. Eu iria apagá-los à vista. Eles tornar o código menos legível.

Os comentários devem estar lá para ajudar o programador que está lendo o código, explicar coisas, etc.

Outras dicas

A razão válida que posso pensar é este (fictício) exemplo:

# removed the following test because this should work now that bug #12345 is fixed.
#assert a != 0
b = number / a

Basicamente, para manter outros desenvolvedores de reinserir o código que foi removido por uma razão.

Diga aos empreiteiros que parar de fazer isso. Esta é uma prática terrível.

Não há realmente qualquer razão para manter o código antigo na base de código; ele só fica no caminho. Seu sistema de controle de versão irá mostrar-lhe a história de cada arquivo.

A única possivelmente boa razão para manter o código antigo, há, possivelmente, para referência histórica (talvez se o código antigo fez algo particularmente estranho que possa ser relevante para a situação actual).

Às vezes eu só vai comentar o código sabendo que eu estou colocando uma mudança temporária no (por temporários quero dizer menos do que alguns dias) e definitivamente plano para voltar a ele.

edit: outra prática relacionada é colocar nomes e datas de mudanças no arquivo:

// 06/20/2009 - joe changed this #1245

Não faça isso também. Pode parecer valiosa na hora de ver quem fez uma alteração, mas com o tempo realmente não tem qualquer valor e também atravanca o código.

Se você estiver usando o controle de origem que você deve ser, em seguida, remover o código antigo como uma cópia será no controle de origem pronto e esperando por você, se você precisar adicioná-lo de volta. Tendo o velho código lá vai reduzir a capacidade de ler o código como dito acima e introduzir confusão. Além disso, se você estiver usando contratados para escrever o seu código de dizer-lhes como código como você está pagando seus salários. Definir padrões de codificação para eles e levá-los ao código pela intenção que deve melhorar o nome de métodos, propriedades, etc, e reduzir a necessidade de comentários todos juntos.

Você pergunta "quanto tempo?" Eu não estou ofendido por ter código antigo em um ou dois lugares, se esses são os pontos quentes onde as pessoas ainda estão trabalhando.

Talvez eles não se sentir confiante sobre o novo código ainda. É o novo código "feito?" Está escrito como deveria ser? Será que passar por testes? É comentado e documentado para especificação? É o desempenho onde deveria estar? (A melhor razão que eu posso pensar em ter o código antigo e novo, tanto ao redor é quando estou sincronismo ou perfil de um determinado conjunto de casos.)

Existe alguma coisa sobre o código antigo que é preferível para o novo código?

Será que os empreiteiros se sentir em uma corrida? Ou é apenas um velho hábito de dias de controle pré-versão?

Quando você lembrar os empreiteiros que não tem que comentar código como Sourcesafe irá manter a história perguntar-lhes porque eles estão fazendo isso.

Pode ser que eles não confiam que por algum motivo. Se você pode obter esse motivo deles eles podem prestar atenção. Eu sei que quando nos mudamos de VSS muitos anos atrás era por causa de problemas de confiabilidade e escalabilidade que eles possam ter sido expostos ao bem. Se você pode resolver suas preocupações, quer demonstrando que o VSS é adequado para as suas necessidades ou dizendo que você vai investigar outras soluções de controle de origem (se você tiver o orçamento para ele, claro), você deve conquistá-los.

A persuasão é melhor do que a coerção.

Sim bombardeá-lo à vista. Ele não dá valor diferente que para mostrar que o desenvolvedor que comentou ele quer não tinha certeza sobre a remoção do mesmo. Ou eles não sabem como usar seu software de controle de origem.

Basicamente, você só tem 2 opções.

  1. Remova-o - é quando você usa algum repositório de código. Seu repositório irá dizer-lhe exatamente quais alterações foram feitas para que não haja necessidade de manter observações longa antigos em seu código de trabalho, que não explica algo em linguagem fácil.
  2. Por outro lado, se você deseja manter esse código por várias razões, exemplo, eu mantive um código de cálculo de ponto flutuante no meu aplicativo comentado, porque não trabalhar sobre a plataforma, eu estava programando para. Mas como eu não gostaria que meu pedido para ficar limitado a essa plataforma, eu mantive o código lá, por isso poupa o esforço quando eu portar o aplicativo para uma plataforma que fizeram cálculos de ponto de apoio flutuantes. Esta é apenas uma das razões para manter o código antigo, e pode ser aplicável a pessoas do mesmo fundo.

Caso contrário, acima indicado são suas únicas duas escolhas. Sua chamada !!

Manter o código antigo em torno de apenas torna mais difícil para ler o código como um todo. Contanto que haja alguma forma de controle de versão no local para o projeto, o código comentado deve ser suprimida. Se você não tem controle de revisão e não pode definir qualquer-se, em seguida, colocar o código antigo em um arquivo em algum lugar que não fazem parte da base de código é aconselhável.

Eu estou supondo que você se referem a blocos de código significativas que parecem ser de algum valor, ou bons algoritmos, por direito próprio, e não apenas a linha estranha aqui ou ali.

Nestes casos, há uma tendência natural para manter o código, se você fez grandes mudanças mantendo a traça antiga como comentários atua como uma forma de revisão do código. Qualquer pessoa recebendo a versão mais recente será capaz de ver instantaneamente as grandes alterações que foram feitas, e se houver um problema, o seu visto muito mais facilmente o que costumava estar lá. Se o problema é com o novo código, em seguida, há uma maneira muito simples para verificá-lo imediatamente.

Assim, uma vez que, eu tendem a comentar código antigo para a primeira revisão, e só então excluí-lo quando o código é posteriormente mudou de novo, por esta altura a mudança terá sido 'camas em' e não susceptível de ser uma causa de erros.

Estes comentários são uma forma de documentação, não há necessidade de removê-los para qualquer purista ideal de 'clean' codificação. Removê-los quando eles não são mais necessários, mantê-los enquanto eles podem ser de valor.

Em primeiro lugar, eu digo se livrar dele.

Mas eu sei uma razão para não: enquanto ele ainda está lá no seu controle de versão, que faz alguém não média pode vê-lo. Se você pode precisar para vê-lo novamente, você primeiro tem que saber que existiu uma vez. Às vezes você faz uma modificação que futuros desenvolvedores precisam ver tanto o caminho antigo e novo e se você remover a velha forma, como é que os devs sei que foi uma vez lá? A maioria das pessoas não alterações do documento em controle de versão bem o suficiente para este tipo de problema.

Assim, muitas razões para deixar o código antigo lá. Basicamente - uma vez que é eliminada é efetivamente desaparecido - a menos que alguém realmente se lembra que estava lá.

Como um empreiteiro mal eu faço código não excluir a menos que eu estou fazendo uma reescrita substancial de um procedimento - a demolição-lo e substituí-lo em vez de "fixação"-lo.

O projeto que estou actualmente a introduzir para, usos ainda outra abordagem - algum tipo de compromisso ... Quando você decidir, que alguma parte do código não é para ser usado, basta comentá-la, escreva uma data de comentando, e (se é possível - por exemplo, no Netbeans ou VisualStudio) inserir o antigo código em #region OLD_IMPL. Efeito? - Você ainda tem um código antigo para o caso - Bloco de código não utilizado leva exatamente 1 linha (#region OLD_IMPL) - Se você vê, esse código não é usado por um ano (você tem data de comentando-lo), você pode simplesmente excluí-lo.

Em caso de situações críticas que você use sempre SVN;)

Aqueles que dizem que para se livrar da comentou-out-código porque as ferramentas de controle de versão irá resolver qualquer problema que você pode executar em, são idiotas.

Você precisa se livrar de código obsoletos, uma vez que são POSITIVAMENTE certeza de que ele é realmente muito obsoleta.

Já teve de rever uma modificação porque "não foi totalmente ruim, mas, infelizmente, não era inteiramente bom, quer"? Se você ainda pode tirar a fonte de produção e saber que a versão anterior do código ainda está lá, de alguma forma textual, você vai economizar muito tempo, porque você não vai precisar de recorrer ao complexo, de difícil -control e, portanto, próprios processos erro de pronce de usar qualquer "fusão parcial fonte" e "consolidação parcial fonte" que a ferramenta de controle de versão pode lhe oferecer.

As pessoas que não gostam dessa realidade certamente deve ter passado toda a sua carreira produzindo apenas código que nunca foi "não é totalmente ruim, mas não inteiramente bom também", ou em outras palavras, produzindo apenas o código que era ou totalmente ruim ou mais inteiramente aperfeiçoar. E todos nós sabemos como é grande a probabilidade é de alcançar o último.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top