Os comentários TODO fazem sentido? [fechadas]

Eu costumo usar // todo comentários para coisas que têm acontecer, mas não posso fazer imediatamente.

Eu também me certifico de que eu corri atrás deles - eu procuro por eles (o Visual Studio tem um ótimo recurso onde ele irá listar tais comentários para você) e garanto que as coisas são feitas.

Mas, como você diz, nem todo mundo é diligente com eles e, como muitos comentários, eles tendem a apodrecer com o tempo.

Eu diria que isso é mais uma preferência pessoal - desde que você documente o que precisa ser feito e busque, não importa se está em // todo , postit notes ou um quadro branco (onde eles também podem acabar não sendo acionados).

IDEs modernos reconhecem os TODO comentários e eles são visíveis em seus próprios painéis / janelas / guias, então eles teoricamente não são perdidos (estou pensando no Eclipse e no Visual Studio, ambos sei o suficiente para lembrar que eles reconhecê-lo).

Você pode até configurar palavras de comentários adicionais, como FIXME , BEWARE ou qualquer outra coisa que você queira personalizar. No entanto, outros desenvolvedores em seu projeto terão que personalizar seu IDE da mesma maneira.

Agora, eu escrevi "teoricamente" porque, embora não seja perdido, o TODO mais frequentemente se refere a algo que não é necessário para que o aplicativo funcione corretamente "no momento". E "no momento" pode se estender por 5 minutos a 5 anos, dependendo do tipo / tamanho do projeto: -)

Finalmente, na minha opinião, ainda faz mais sentido tê-los no código, no lugar certo, precisamente respondendo a pergunta "onde devo fazer a mudança" do que em outro lugar fora do código.

Editar: como está escrito no artigo sobre comentários da Wikipédia, incluindo a data e o proprietário do TODO é considerado uma boa prática.

Pode fazer algum sentido, pelo menos eu os uso algumas vezes. O ponto principal é usar tags consistentes, como TODO ou FIXME , para que possam ser facilmente encontradas com a pesquisa de texto simples.

Por exemplo, soluções "rápidas e sujas" são convenientes para rotular, algo como:

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

Se o código faz o que é suposto fazer, e ninguém reclama, então o comentário não faz mal. Se houver tempo para embelezar o código, é fácil começar a pesquisar por FIXME labels.

No meu setor, os desenvolvedores são encorajados a fazer entradas do JIRA (ou etc) em vez de comentários do todo, porque nem todo mundo tem a chance de ver as entradas // todo . Mas às vezes, em grandes projetos, um atributo personalizado é definido nos seguintes termos:

[AttributeUsageAttribute(AttributeTargets.All, AllowMultiple = true)]
public class DeveloperNote : Attribute
{
    public DateTime EntryDate { get; set; }
    public string Description { get; set; }
    public DeveloperNote(int year, int month, int day, string desc)
    {
        EntryDate = new DateTime(year, month, day);
        Description = desc;
    }
}

E então um método pode ser decorado dessa maneira ...

[DeveloperNote(2011, 12, 13, "Make the db connection configurable")]

E os superiores podem aparecer e coletá-los automaticamente. Pode ser um exagero para o lembrete simples de // todo , mas é eficaz. Também requer uma plataforma .NET.

Na minha experiência, isso depende. O principal fator é se a equipe é disciplinada o suficiente para acompanhar esses "pequenos" comentários. Se eles fizerem sim, eles fazem sentido. Se não o fizerem, esses comentários são apenas uma perda de tempo e você pode querer examinar outras opções, por exemplo, cartões de história.

A minha preferência seria sempre não usá-los e, em vez disso, usar cartões de histórias ou pendências apropriados ou semelhantes. Use um mecanismo para uma tarefa.

TODO é apenas um subformulário de comentário. Os comentários têm grande utilidade se o escritor tiver habilidade suficiente para saber o que transmitir e como transmiti-lo. Um senso de humor também pode ser aplicado aqui em pequenas doses para deleitar os mantenedores anos mais tarde.

Recebi uma ligação no ano passado dizendo que parte do meu código estava sendo retirado. Fiquei bastante impressionado por estar em produção e ter sobrevivido à manutenção por 16 anos. Portanto, esteja ciente de que seu código pode durar muito tempo. Comentários sobre intenção, necessidades futuras e assim por diante podem ajudar muito alguém daqui a alguns anos a olhar para o seu código pela primeira vez.

Eu costumava escrevê-los no passado, mas descobri que você não costuma acompanhá-los.

Portanto, agora eu só os uso para marcar as coisas que quero trabalhar logo depois de terminar o que estou ocupado. Por exemplo, eu implemento uma nova função e percebo que uma função que eu uso tem um pequeno bug; Eu faço um FIXME para corrigir isso para evitar descarrilamento na minha tarefa atual.

Para me ajudar, nossas construções de CI são configuradas para falhar se houver FIXMEs no código: -).

Se você perceber possíveis problemas que não podem ser resolvidos imediatamente, abra um ticket / bug / problema para eles. Dessa forma, eles podem ser priorizados como todos os bugs. Eu sinto que isso é muito melhor do que ter alguns problemas no banco de dados do bug e alguns no código como TODOs.

Opcionalmente, você pode colocar um TODO com o ID do bug: -).

Acho que TODO comentários, até certo ponto, fazem sentido. Particularmente, se você estiver trabalhando iterativamente (como é comum em lojas ágeis e TDD), haverá coisas que você reconhece que são necessárias em pouco tempo, mas que você não quer fazer o desvio para implementar logo ali.

O que é feio é quando esses comentários permanecem na base de código. Enquanto você está trabalhando ativamente em um recurso, não há problema em deixá-los entrar, mas assim que você estiver mais perto de completar o recurso, você deve se concentrar em se livrar deles. Se você não quiser passar pelo trabalho de realmente substituí-los pelo código de trabalho adequado, considere pelo menos a funcionalidade relevante. Para emprestar o exemplo de @JoonasPulakka, onde o código inicialmente diz

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

você pode mudar isso para algo como

ConnManager.getConnection(GetDatabaseName());

com, por enquanto, GetDatabaseName () sendo um stub que simplesmente retorna a mesma string que você iniciou. Dessa forma, há um ponto claro de expansão futura, e você sabe que quaisquer alterações feitas lá serão refletidas em qualquer lugar onde o nome do banco de dados é necessário. Se o nome do banco de dados for ainda moderadamente genérico, isso pode ser uma grande melhoria na capacidade de manutenção.

Pessoalmente, eu uso uma palavra-chave minha em vez de estritamente TODO , embora a intenção seja a mesma: marcar coisas que eu sei que precisarão revisitar. Além disso, antes de fazer o check-in do meu código, faço uma pesquisa global de código-fonte para essa palavra-chave, que é escolhida de modo que normalmente ela não apareça em nenhum lugar do código. Se for encontrado, sei que esqueci alguma coisa e posso ir em frente e corrigi-lo.

Quanto a incluir o nome / assinatura do programador com o comentário, acho que é um exagero se você tiver um sistema de controle de versão do código-fonte (você faz