comentários número de bug

Question

Por que você adicione

// Bug 1024

comentários em uma base de código controlado fonte? A maioria dos sistemas de rastreamento de bugs e de controle de origem são melhor equipted para acompanhar esta informação. No controle de origem, um rótulo ou comentário pode ser usado com o check-in. Em um bug tracker o número de revisão pode ser adicionado a resolução do bug. Então, por que comentar o código? Especial desde que estes comentários relevância é muito curta e eles tendem a acumular-se desarrumar a base de código.

Answer 1

Eu encontrei um desses útil no outro dia na nossa base de código.

Eu disse "por que ele está chamando a função de inicialização uma segunda vez, esta tarde no fluxo de trabalho ??"

O comentário bug deixe-me ir para a direita a descrição do problema. Quando eu refeito o código, eu tinha certeza de incluir esse bug em meus testes e não reintroduzi-lo.

Embora eu vou dizer que, em geral, eu concordo com você e não insira os mim mesmo.

Eu teria preferido que o desenvolvedor em questão reparou o erro de uma forma mais significativa, de modo que eu não tinha a se perguntar sobre o código em primeiro lugar.

Answer 2

Em última análise, eu acho que é uma prática ruim. É melhor incluir porque o erro existe (foos do tipo Y não tem a propriedade Z). Você pode incluir uma "mais em BUGID 12345" junto com isso se quiser.

Se você está integrando em vários níveis, uma visão código-fonte em trac pode ligar diretamente para o BUGID.

Answer 3

pura preguiça. Claro, é preciso mais tempo, a longo prazo, mas no curto prazo "// Erro 1024" toma qualquer esforço. Quanto mais código que você tem, pior é.

Answer 4

Imagine que você tem um novo bug que você rastrear a mudança na revisão 12345. Você olha para os logs e imediatamente lhe diz que Bug 1024 foi o motivo da alteração foi feita.

Você pode então ir e olhar para 1024 para ver o que, por que e quando, antes de fazer uma nova correção -. A 'um para governá-los todos'

Se o número bug não está na mensagem de confirmação, você tem que, em seguida, procurar o erro que um commit fixo - e que pode ser várias (se o bug é reportado mais de uma vez)

.

Answer 5

Eu penso que este é um caso de "Eu tenho um martelo, que deve ser um prego". O seu editor de texto ou IDE não é sua única ferramenta para gerenciar o código.

A história é melhor mantido externamente ao código. O significado do código deve ser descrito em comentários quando não imediatamente óbvio.

Eu concordo que os números de erros deve estar em controle de origem cometer mensagens.

Answer 6

Você nunca deve adicionar apenas o número de bug. Você deve adicionar o número de erros e o assunto e quaisquer qualificadores se você fez várias checkins para um único erro:

Bug 1111 - Foo preso em sistemas de 64 bits. Fix # 2 porque foi re-inaugurado após a mesclagem para tronco.

Alguns sistemas têm bug integração número. Em mxr.mozilla.org o número bug nas cvs log exibição é auto-magicamente transformado em um link para o número bugzilla.mozilla.org. Quando você está cavando no código, esta é uma grande economia de tempo. Eu acho que Fogbugz tem um recurso similar ...

Além disso, mesmo se o sistema não faz, que muitas vezes ajuda porque ninguém quer ver todo o contexto da mudança de comentários, que é o que o bug tracker é para.

Answer 7

Eu concordo com você que o comentário como este não é realmente útil e é muito breve.

No entanto, é extremamente útil e importante para comentar o código com referências aos registros nos defeitos sistema de rastreamento (ou para que se estendem a qualquer KM repositório você pode ter).

Às vezes, um código é alterado para implementar uma solução para um determinado problema com o comportamento do aplicativo. Às vezes, a solução introduzida não é de forma lógica. Muitas vezes acontece que quando um código é atualizado por outra pessoa esta peça 'ruim' de código é removido como parte do esforço de re-factoring.

Assim, marcando um código como pertencente a um determinado bug-fix torna visível durante a re-factoring, o que levou o desenvolvedor para rever a descrição do bug antes de alterar o código. Ele também ajuda na situação em que o bug é re-aberto -. Se você tem que mudar a mesma parte do código várias vezes que você pode considerar investir tempo em uma solução alternativa

P.S. você pode considerar este artigo sobre MS Office a partir Joel On Software útil. Tanto quanto eu sei o código de MS Office e MS Windows está cheio de comentários semelhantes que explicam as decisões tomadas pelos desenvolvedores há muito tempo.

Answer 8

Acho que é útil ao explicar código que de outra forma parece errado, e também para uso nas mensagens.

Answer 9

Eu não faço isso. Eu não posso pensar em uma boa razão por que você iria colocar o ID defeito no código. Vou colocar isso nas notas de lançamento / changelog vez.

O que eu achar útil é usar o defeito Id como parte do nome nos testes automatizados:

[TestFixture]
public class Release_1_2_Bugfixes
{
  [Test]
  public void TestBug42()
  {
    Assert.AreEqual(42, CalculateAnswerToLifeUniverseAndEverything());
  }
}

Eu vi outros projetos fazendo a mesma coisa.

Answer 10

Estou surpreso com quantas pessoas se opõem a isso. Meu sentimento pessoal sobre isso é que estes são muito boa idéia. Concordo com um comentário anterior que deve incluir mais do que apenas o número bug, e de preferência incluem um pequeno resumo e um link para o sistema de rastreamento de bugs, se necessário.

O benefício para esses comentários só é óbvia em um projeto mais velho com história e um grande número de correções de bugs anteriores. Você não tem que fazer estes comentários em todos os lugares, mas eles são muito, muito útil quando colocado diante de um bloco de código que pode não fazer sentido sem contexto. Em qualquer tipo de sistema razoavelmente complexo, haverá trechos de código que parecem ilógicas ou desnecessários, sem contexto.

Devido às interações com o sistema ou soluções alternativas de idade, o código é necessário. A fim de impedir que alguém depois reintroduzir um bug remendada, é extremamente útil para denotar o bug do bloco de código é projetado para correção, de preferência com algum tipo de explicação em anexo. Caso contrário, você está dependendo de alguém verificar o histórico de cometer cuidadosamente por uma razão registradas no log de cometer, que é altamente improvável, especialmente se alguém é um código de refatoração.

Editar : Estou me referindo especificamente ao colocá-los com um bloco de código que é incomum ou precisa de contexto adicional. Não é útil ou necessário comentar cada correção erro de digitação que você faz: -)

Answer 11

Eu fiz isso até Visual Studio 2008 fornecido com anotação. Ele foi útil quando se olha para trás em código antigo para ver imediatamente que há, pelo menos, pensava-se atrás de uma decisão código particular.

Sim, eu sei que você pode se comparam com as versões anteriores, mas que é essa dor um na bunda quando você só precisa de uma rápida sensação boa sobre atualizações de código menores.

Answer 12

Se você está navegando através de código fonte desconhecida, e você vê algo unobvious, é bom saber o motivo. É uma chamada de julgamento, porém, nem toda correção de bug precisa tal explicação -. Provavelmente a maioria pode ir longe sem ele

Answer 13

Se houver razão suficiente para acreditar que alguém iria querer saber o número bug quando se olha para parte do código, adicionando um comentário mencionar o bug pode ser bastante agradável (espero que parafrasear os bits importantes do bug, bem como, no entanto).

Sim, controle de origem cometer mensagens também devem conter os números de bugs, e olhar através dos registros de revisão pode lhe dar a mesma informação ... mas se a mesma parte do código é alterado várias vezes, mas os detalhes aprendeu com o bug inicial ainda se aplica, pode demorar um pouco para encontrar a mudança original para sempre aprender sobre esse erro.

Além disso, surgem situações em que há uma boa razão para mover o código de uma classe para outra, ou para renomear arquivos, o que tornaria ainda mais difícil de encontrar a raiz da razão por trás de uma determinada seção de código (renomeando não tão um grande problema com o SVN, mas uma dor com CVS).

Answer 14

Você bateu o prego na cabeça com "relevância é muito curta e eles tendem a acumular-se desarrumar a base de código."

Cada pedaço de cruft inúteis que se acumula em arquivos de origem os torna um pouco menos legível e difícil de manter. tudo Excluir que não agregam valor. "Bug 12345" tem pouco valor agora, e terá nenhum em algumas semanas.

Answer 15

Eu trabalho em um sistema de grande escala com muitos desenvolvedores e várias ramificações liberados.

Estes comentários de referência bug pode realmente ser muito útil durante a portabilidade de um galho para outro, especialmente desde que o sistema SCM que uso é muito característica pobres e comprometer comentários são difíceis de obter em ou e poderia ser muito antiga.

Se a correção era simples, então ele pode não precisar de um marcador bug. Se ele não é óbvio, pode fazer mais sentido para se referir a um erro depois de escrever uma longa explicação em uma seção de comentários.

Answer 16

Não gosto deste tipo de graffiti. Como outras formas de vida desagradáveis ??que agregar ao longo do tempo, sufocando a base de código.

O problema realmente começa quando as pessoas fazem correções de bugs que se sobrepõem uma correção de bug anterior. Então você tem os números de erros de rotulagem uma seção de código que são simplesmente errados ou enganosa.

Answer 17

Este tipo de comentário é muito útil: o que acontece quando você muda as ferramentas de rastreamento de bugs ou de controle de origem? Uma referência a BZ1722 vs FB3101 iria dizer-lhe que ferramenta de rastreamento para verificar (Bugzilla ou FogBugz por exemplo).

Answer 18

É uma coisa boa! ??

A pessoa que está olhando para o código é improvável a apreciar a história completa do código e é provável que desfazer uma alteração muito importante, porque eles não podem ter trabalhado nesta área do código antes. Ele pode explicar o código que de outra forma parece louco ou um requisito do cliente que é equivalente bizarro.

Você não pode sempre capturar as indicações minuciosas das exigências dos clientes através da arquitetura e código, especialmente quando eles pedem algo estúpido. Daí você começar com o sensível e, em seguida, refinar ou cortar o código para o estúpido quando você é forçado a fazê-lo, os números de erros backup da intenção do código louco.