Análise de Código Estático - Quais para ligar primeiro?

Question

Estamos usando VS2008 com o construído em conjunto de código estático regra análise.
Nós temos uma solução C # relativamente grande (mais de 150 projetos) e enquanto alguns dos projetos (<20) estão usando análise estática de código religiosamente, a maioria não é. Queremos começar a aplicar análise estática de código em todos os projetos, mas permitindo que todas as regras criaria uma distração massiva para nossos projetos atuais. Qual das muitas regras de análise estática de código que estão disponíveis devemos ligar primeiro? Que regras têm o maior retorno para os investimentos? Se você pudesse me dar o seu top priorizada 20, eu agradeceria muito.
Agradecemos antecipadamente,
--Ed.S.

Answer 1

As primeiras regras que você deve ativar para um projeto são aqueles para os quais você ainda não tem nenhum violações nesse projeto. Isso permitirá que você para evitar a introdução de novos problemas sem lhe custar qualquer esforço de limpeza adicional.

Quanto ao resto, uma vez que você já está usando análise de código em outros projetos, o seu melhor contributo para que as regras são mais susceptíveis de serem quebrados com graves consequências é, provavelmente, os desenvolvedores que trabalham com esses projetos. Se você não tem sobreposição suficiente entre os projectos para obter feedback significativo de desenvolvedores, você pode querer considerar começar com as regras que estão incluídos no Microsoft mínimo Recomendado Regras conjunto de regras no Visual Studio 2010.

Se você está pensando em realmente limpar as violações existentes em qualquer projeto, você pode querer considerar o uso de FxCop em vez de VS análise de código até que a limpeza esteja concluída. Isso permitiria que você a normativa ativar imediatamente, mantendo "para clean-up" exclusões de violações existentes fora do seu código-fonte.

Answer 2

Tendo em conta que os Estúdio são semelhantes às regras do FxCop, posso dizer-lhe quais eu ligar última .

Se a internacionalização não está no horizonte, desligue Regras da Globalização.

Desligue regras de desempenho inicialmente. Optimize quando você precisa.

Coloque os outros a sua equipe e seus projetos. Desligue regras individuais que não são aplicáveis. Em particular, as regras de nomenclatura pode precisar de ser ajustada.

EDIT: A coisa mais importante é reduzir o ruído. Se cada projeto tem 200 advertências e permanece assim durante meses, todos vão ignorá-los. Ligue as regras que importa para a sua equipe, limpar o código para obter 100% passando (ou suprimir as exceções - e não haverá exceções, que são diretrizes)., Em seguida, aplicar mantendo o código limpo

Answer 3

Se você vai localizar o seu projecto / ele vai ser usado em diferentes países, então definitivamente ativar regras de localização. Ele vai encontrar todas as chamadas para todo o tipo de funções Formato / Parse que não especificar CultureInfo. Erros envolvendo não especificado CultureInfo são difíceis de encontrar em testes, mas eles realmente vai morder-lhe no rabo, quando o cliente francês vai perguntar:. Por que seu programa não trabalho / crash em números com "" como separador decimal

Answer 4

No meu código experiência avisos de análise de todos os tipos mostrar erros 'escondidos' ou falhas no seu código. Corrigindo esses podem resolver alguns problemas reais. Eu não encontrei uma lista de avisos que eu gostaria de desativar.

Em vez disso, gostaria de transformá-los em um projeto de cada vez e corrigir todos os avisos que o projeto antes de passar para a próxima.

Se você quer transformar as coisas que eu consideraria não verificar as regras de nomeação (a menos que você está enviando uma biblioteca, APIs ou outros métodos expostos externamente) e regras da Globalização. (A menos que suas aplicações fazem uso ativo da Globalização). Depende um pouco da sua situação que faz sentido.

Answer 5

Eu concordo um pouco com a resposta Jeroen Huinink .

Gostaria de ligar todas as regras que você acha que um projeto deve seguir e corrigi-los o mais rápido possível. Você não tem que corrigi-los todos agora, mas como você atravessa e corrigir um defeito ou refatorar um método em um módulo, você sempre pode limpar os problemas encontrados pela análise estática em que o método ou módulo. Novo código deve aderir a suas regras e códigos existentes devem ser transformados em adesão o mais rápido possível, mas você não precisa largar tudo para que isso aconteça.

Sua equipe de desenvolvimento também pode olhar para as questões para um projeto e priorizá-los, talvez a apresentação de defeitos no seu sistema de gerenciamento de incidentes para os problemas mais críticos para que eles sejam resolvidos rapidamente e pelo desenvolvedor apropriado.