Devo remover o código não referenciado?

A maioria das suas razões para mantê-lo é totalmente irrelevante, em termos simples. Se o código não for usado, jogue-o fora - qualquer benefício envolvido em mantê-lo pode ser derivado do controle de origem. No máximo, deixe um comentário dizendo em qual revisão encontrá-lo.

Simplesmente, quanto mais cedo você cortar o código, mais cedo você não precisará perder tempo para mantê-lo, compilá-lo e testá-lo. Essas vantagens superam amplamente os benefícios triviais que você delineou, e todos podem ser derivados do controle de origem de qualquer maneira.

Todos os motivos para removê-lo permanecem.

Razões para mantê-lo:

• Pode ser usado como referência
• Pode ser útil em algum momento
• Pode ter sido escrito para 'terminar' a funcionalidade de uma classe

Todos esses motivos para mantê-lo serão gerenciados pelo controle de origem. Remova-o do código ativo e você poderá recuperá-lo se / quando for necessário.

O código não referenciado é o mesmo que manter as baterias que estão meio que, meio chatas, para o caso de você precisar delas um dia para uma tocha.

Contanto que você esteja usando algum tipo de controle de versão, eu diria que ele está fora do código ao vivo e use o histórico de versões caso isso seja útil.

A única boa razão que posso ver para manter o código que não está sendo usado atualmente é se ele faz parte de um módulo independente: embora algumas partes do código possam não ser usadas no momento, pode ser que eles serão usados no futuro.

Isso pode ser especialmente verdadeiro para uma biblioteca que você usa em diferentes projetos: você não quer continuar lançando e retirando partes do código, de acordo com o que você precisa para um projeto específico: acho que isso consome tempo e erros. propenso.

Minha abordagem é: (1) se você usar uma vez, mantenha apenas o que realmente precisa; (2) se você usá-lo duas vezes, copie e adapte na segunda vez que você usá-lo; (3) se você usá-lo mais de duas vezes, faça um módulo estável e bem definido, e use este módulo quando precisar.

Resumindo: eu jogaria fora todo o código não utilizado, a menos que seja parte de um módulo de propósito geral que você tenha criado como tal e que você saiba que vai reutilizar várias vezes.

Nota : É claro que uma solução ainda mais limpa seria criar um projeto separado para uma biblioteca e adicionar uma dependência entre projetos.

Geralmente, eu me curvaria a YAGNI sobre isso. Se "você não vai precisar", então é simplesmente ocupar espaço na sua base de código, testes de unidade e montagens. Você pode acabar precisando, mas você também pode acabar precisando reescrevê-lo completamente, porque entre agora e quando você precisar de algo parecido, muita coisa pode mudar.

No entanto, isso muda um pouco quando você está escrevendo um utilitário ou uma API destinada ao consumo geral. Assim como você nunca pode esperar que os usuários finais de software interajam com o software da maneira pretendida, você nunca pode esperar que os consumidores do seu código queiram usar seu código exatamente da maneira que você acha que eles deveriam. Nesses casos, contanto que você possa justificar a existência de um método com "é uma maneira válida de querer interagir com meu objeto", provavelmente ele deve entrar, porque mesmo se você não precisar, as chances são boas ALGUÉM .

Dado que a base de código tem menos de um ano, provavelmente ainda está em muito fluxo (sim?) - então a noção de que alguns bits podem precisar ser ressuscitados em um futuro próximo não é irracional.

Para bits que eram difíceis de acertar em primeiro lugar e parecem mais propensos a ser ressuscitados, eu os manteria um pouco mais "vivos" do que apenas no controle de origem. As pessoas não sabem / lembram que elas existem - dizendo "você pode encontrá-las apenas no controle de origem" presume que você sabe / lembra que está lá! Nesse tipo de casos, considere a depreciação (com um "assert (falso)" showstopper) ou comentando.

Se o código é trivial e desinteressante, eu simplesmente jogo fora para livrar-se da inércia desnecessária do sistema de software.

Para cadáveres de códigos interessantes, eu uso uma ramificação archive em meus sistemas de controle de versão.

Um bom motivo para manter os métodos não utilizados é: eles podem ser usados em outros ramos / tags!

Explore todos os seus ramos e tags ativos antes de removê-los.

Se você usa um sistema de controle de versão, não se preocupe com referências futuras, pois você pode ver o histórico desse código e encontrar a parte excluída. Se você não o fizer e achar que ele seria usado algum dia, simplesmente deixe-o ficar lá, mas comente com uma descrição explicando por que ele é comentado.

No entanto, se tiver certeza de que não será mais usado no futuro, basta removê-lo . Eu acho que as razões que você mencionou são bastante simples para o código ser removido.

Mas antes de removê-lo, certifique-se de que ele não seja usado em lugar algum. O Visual Studio tem um recurso chamado Localizar todas as referências que pesquisa toda a solução e localiza qualquer referência à variável, método, propriedade, classe, interface atual, etc. Sempre me certifico de que nenhuma referência está em vigor antes de remover parte do meu código.

Eu tenho tido a experiência de encontrar uma função que parece que vai fazer exatamente o que eu preciso, e confiando que funcione já que está em produção há muito tempo, só para descobrir que ela não tem realmente utilizado há vários anos. O código que não é usado não é mantido e, embora possa ter funcionado anos atrás, a API mudou o suficiente e você não pode confiar nele.

Na melhor das hipóteses, você acaba gastando muito tempo, certificando-se de que, na verdade, ainda faz o que você quer. Na pior das hipóteses, parece funcionar até que você seja mordido por um erro desagradável mais tarde, e demore mais para rastreá-lo porque você assumiu que o código "testado na produção" funciona, portanto o problema deve estar em outro lugar no novo código. Na minha experiência, é quase sempre mais rápido escrever uma nova função sozinho.

Se você excluí-lo, mas descobrir relativamente em breve, você realmente precisa dele, está bem ali no controle de origem. Se você não precisa dele até que passe tanto tempo que você não se lembre de estar no controle de código-fonte, provavelmente é melhor escrevê-lo do zero de qualquer maneira.

Nada consome menos tempo do que nenhum código.

Se você tiver que mergulhar em uma base de código, precisará de algum tempo para descobrir, para que esse código é usado e, se não for usado para nada, você precisará de mais tempo.

Ok - isso poderia ser curado como um comentário, mas, novamente, todo mundo vai raciocinar sobre por que esse código não utilizado ainda está na base de código, se deve ser removido ou não.

Se não houver nada, ninguém perderá tempo com isso.

Se foi difícil acertar, você precisa de uma boa documentação, que esse código existe, mas se a base de código evoluir durante algumas iterações, talvez não funcione mais, se for reativado.

Remova o código não utilizado - menos confusão, melhor compreensão. Seu sistema de controle de versão cuidará disso. Além disso, se você estiver usando algo melhor do que o bloco de notas, seu ambiente permitirá que você use códigos mais antigos para referência.

Comentários longos do código antigo distraem e dificultam a navegação.

Atenciosamente

Siga este algoritmo simples:

1. É feito backup em um SCM? Se sim, pule para 3.
2. Configurar um SCM.
3. Jogue as coisas fora .

Todos os seus pontos em favor da remoção são válidos.

Todos os seus pontos em favor de manter a desordem são inválidos quando você tiver um SCM para procurá-lo ou restaurá-lo. Na verdade, seu SCM deve ser capaz de ajudá-lo a determinar por que esse código está aqui e não é usado, se ele foi usado corretamente.

É chamado de "código morto" por um motivo. Deixe-o morrer e descanse em paz.

"Pode ser usado como referência" Eu não tenderia a concordar em ser um bom motivo para deixar um código não utilizado. Muitas vezes, apenas uma pequena parte do código não utilizado está realmente demonstrando algo interessante. Existem várias maneiras de documentar e armazenar códigos úteis, mas não utilizados.

Embora o controle de versão contenha um histórico que lhe permitirá facilmente restaurar uma funcionalidade particular se você decidir posteriormente que o código é necessário, sabendo que você precisa procurar no histórico de controle de versão para encontrar xy ou z de quem sabe A revisão pode ser um pouco entediante, e muitas vezes é esquecida, a menos que você tenha uma ideia bastante específica do que está procurando.

O código pode ser comentado com uma observação sobre quando foi removido e porque não foi simplesmente excluído do código. No entanto, isso geralmente é considerado um estilo ruim, e o código que não é usado e não é mantido corretamente pode introduzir todos os tipos de bugs se ele não for mais comentado posteriormente, então isso é melhor como uma etapa temporária de depuração / teste enquanto refatorando uma maneira de deixar o código de produção.

Minha maneira favorita de armazenar o código excluído, se ele parecer útil no futuro, é fazer um documento de referência secundário contendo todos os vários fragmentos de código deletado que vale a pena. Cada bloco de código é rotulado com uma breve menção de onde ele veio ou qualquer outra coisa pertinente a lembrar, como quando foi removido ou o último número de revisão no código em. Tudo removido, mas "potencialmente útil" está em um lugar, facilmente pesquisável, mas não requer esforço constante para manter e testar em uma base contínua (que o teste é deferido para qualquer ponto que o código seja reintroduzido).

Ele permanecerá no controle de origem; não deve ficar na base de código ativo.

A única exceção é se o código conclui o design e, embora você não esteja usando o código, planeja tornar o código público e outras pessoas podem querer essa funcionalidade básica. Em seguida, basta projetar testes para garantir que essas partes do código funcionem e imitem a forma como você propõe que outras pessoas usem essas partes do código. No entanto, se você está mesmo considerando a exclusão do código e não pode vir com uma razão sólida para mantê-lo, ele deve ir. Código não utilizado faz mais trabalho para todos (mais difícil de ler o código; o código pode estar quebrado; mais trabalho para manter; etc.)

Na minha experiência, a remoção de código não utilizado também pode ser contraproducente. Você pode esquecer que você tinha esse código e não vai procurá-lo no histórico. Ou talvez você nem saiba que alguém implementou esse código e o removeu depois. Mais uma vez, você não vai procurá-lo na história ...

Sem dúvida, ter código não utilizado é um mau cheiro.

ATUALIZAÇÃO: Eu só notei que Ed Staub deu uma resposta muito semelhante.