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