Encontrar código não utilizado

Eu tenho que refatorar um grande aplicativo C #, e eu encontrei um monte de funções que nunca são usadas. Como posso verificar se há código não utilizado para remover todas as funções não utilizadas?

É uma ótima pergunta, mas esteja avisado de que você está pisando em águas perigosas aqui. Quando você estiver excluindo o código, você precisará certificar-se de que está compilando e testando com frequência.

Uma ótima ferramenta vem à mente:

NDepend – esta ferramenta é simplesmente incrível. Demora um pouco para grok, e após os primeiros 10 minutos eu acho que a maioria dos desenvolvedores apenas dizem “Screw it!” e exclua o aplicativo. Uma vez que você tenha uma boa noção do NDepend, você terá uma visão incrível de como seus aplicativos estão acoplados. Confira: http://www.ndepend.com/ . Mais importante ainda, esta ferramenta permitirá que você visualize methods que não tenham nenhum chamador direto. Ele também mostrará o inverso, uma tree de chamada completa para qualquer método na assembly (ou até mesmo entre montagens).

Seja qual for a ferramenta escolhida, não é uma tarefa negligenciável. Especialmente se você estiver lidando com methods públicos em assemblies de tipo de biblioteca, como você pode nunca saber quando um aplicativo está fazendo referência a eles.

Resharper é bom para isso, como outros afirmaram. Tenha cuidado, porém, essas ferramentas não encontram o código que é usado pela reflection, por exemplo, não pode saber se algum código não é usado pela reflection.

Como apontado Jeff, a ferramenta NDepend pode ajudar a encontrar methods, campos e tipos não utilizados.

Para elaborar um bit, o NDepend propõe escrever uma Regra de Código sobre a Consulta LINQ (CQLinq) . Cerca de 200 regras de código padrão são propostas, sendo 3 delas dedicadas à detecção de código morto / não utilizado

Basicamente, tal regra para detectar um método não utilizado, por exemplo, se parece com:

// Dead Methods warnif count > 0 from m in Application.Methods where !m.MethodsCallingMe.Any() select m 

NDepend regra para encontrar métodos não utilizados (métodos mortos)

Mas essa regra é ingênua e retornará falsos positivos triviais. Existem muitas situações em que um método nunca é chamado, mas não é utilizado (ponto de input, construtor de class, finalizador …) é por isso que as 3 regras padrão são mais elaboradas:

  • Tipos potencialmente mortos (portanto, detectam class não utilizada, estrutura, interface, delegado …)
  • Métodos potencialmente mortos
  • Campos potencialmente mortos

O NDepend integra-se no Visual Studio 2017, 2015, 2012, 2012, 2010, portanto, essas regras podem ser verificadas / navegadas / editadas diretamente dentro do IDE . A ferramenta também pode ser integrada ao seu processo de IC e pode criar relatórios que mostram regras violadas e culpam elementos de código. O NDepend também possui uma extensão do VS Team Services .

Se você clicar nesses três links acima em direção ao código-fonte dessas regras, verá que os tipos e methods são um pouco complexos. Isso ocorre porque eles detectam não apenas tipos e methods não utilizados, mas também tipos e methods usados apenas por tipos mortos e methods não usados ​​(recursivos).

Esta é uma análise estática , portanto, o prefixo Potencialmente nos nomes das regras. Se um elemento de código for usado apenas por reflection, essas regras poderão considerá-lo como não usado, o que não é o caso.

Além de usar essas três regras, eu aconselharia a cobertura do código de medição por testes e se esforçaria para ter cobertura total. Muitas vezes, você verá que o código que não pode ser coberto por testes, na verdade, é código morto / não usado que pode ser descartado com segurança. Isso é especialmente útil em algoritmos complexos em que não está claro se uma ramificação de código está acessível ou não.

Disclaimer: Eu trabalho para o NDepend.

Eu também mencionaria que usar o IOC aka Unity pode tornar essas avaliações enganosas. Eu posso ter errado, mas várias classs muito importantes que são instanciadas via Unity parecem não ter nenhuma instanciação até onde o ReSharper pode dizer. Se eu seguisse as recomendações do ReSharper, eu seria curado!

O ReSharper faz um ótimo trabalho ao encontrar código não utilizado.

No VS IDE, você pode clicar com o botão direito na definição e escolher ‘Localizar todas as referências’, embora isso só funcione no nível da solução.

Eu me deparei com AXTools CODESMART..Tente isso uma vez. Use o analisador de código na seção de avaliações. Ele listará as funções locais e globais inativas juntamente com outras questões.

FXCop é um analisador de código … Ele faz muito mais do que encontrar código não utilizado. Eu usei o FXCop por um tempo e fiquei tão perdido em suas recomendações que o desinstalei.

Eu acho que o NDepend parece um candidato mais provável.

A verdade é que a ferramenta nunca pode lhe dar uma resposta 100% certa, mas a ferramenta de cobertura pode lhe dar uma boa corrida pelo dinheiro.

Se você contar com um abrangente conjunto de testes unitários, poderá usar a ferramenta de cobertura de teste para ver exatamente quais linhas de código não foram executadas durante a execução do teste. Você ainda precisará analisar o código manualmente: elimine o que considera código inativo ou teste de gravação para melhorar a cobertura do teste.

Uma dessas ferramentas é o NCover , com o precursor de código aberto no Sourceforge . Outra alternativa é o PartCover .

Confira esta resposta no stackoverflow.