O que é análise de código?
A análise de código (anteriormente FxCop) é uma ferramenta de análise estática que procura padrões comuns que podem indicar que algo está errado no código fonte. Por exemplo, se uma instância de uma classe implementada IDisposablenão for descartada corretamente, a análise de código emitirá um aviso:
private void DoSomething()
{
var connection = new SqlConnection(...);
this.ChangeSomeData(connection);
}
Esta é a implementação correta do trecho de código anterior:
private void DoSomething()
{
using (var connection = new SqlConnection(...))
{
this.ChangeSomeData(connection);
}
}
Como qualquer ferramenta de análise estática, a análise de código destina-se a encontrar padrões que são pesados (ou simplesmente chatos) para serem encontrados manualmente. Por exemplo, no exemplo anterior, pode ser bastante chato para um desenvolvedor verificar se alguma classe que ele usa implementa IDisposable(ou lembrar de todas as classes do .NET Framework que a implementam).
Quais projetos se qualificam?
Embora esteja sujeito a falsos positivos, como qualquer ferramenta de análise estática, geralmente é benéfico direcionar zero avisos para códigos críticos para os negócios sem usar supressões . No Visual Studio, a análise de código pode ser configurada para ser executada em tempo de compilação; se as configurações do projeto também especificarem que os avisos devem ser tratados como erros, as violações das regras de análise de código não passarão despercebidas.
Como a análise estática pode levar algum tempo para projetos médios ou grandes, geralmente é uma boa ideia movê-la das máquinas do desenvolvedor para o servidor de construção do TFS. Embora a execução da análise de código durante a pré-confirmação não seja uma boa ideia (diferente do StyleCop), ela ainda pode ser executada na construção e falhar se forem encontrados avisos.
Para código não crítico para os negócios, a análise de código pode ser executada manualmente no Visual Studio ou na linha de comando. As verificações e avisos podem ser detalhados nas propriedades do projeto para atender às suas necessidades. Por exemplo, os avisos de globalização podem ser desativados se o seu projeto não for localizado.
Como no StyleCop, é essencial decidir se o projeto terá como alvo zero avisos da análise de código desde o início do projeto. Introduzi-lo em um projeto existente pode ser muito doloroso.
É diferente do StyleCop?
Observe que a análise de código não é a mesma coisa que StyleCop . A primeira diferença é que a análise de código funciona com o assembly compilado, enquanto o StyleCop trabalha com a própria fonte. A segunda diferença (e mais importante) é que a análise de código procura padrões que possam indicar um erro, enquanto o StyleCop está simplesmente impondo regras de estilo - uma convenção simples usada por sua equipe.
A análise de código também é particularmente útil para iniciantes que não conhecem muito bem o idioma , pois geralmente pode levar ao "Aha!" momentos. Por exemplo, CA2105: Os campos da matriz não devem ser somente leitura, podem levar alguém a descobrir que, mesmo que uma matriz seja marcada como somente leitura, ela não a torna imutável, pois nada proíbe alterar os elementos da matriz. O StyleCop não leva a descobertas: não há nada interessante em saber que os campos começam com uma letra minúscula ou que as chamadas locais devem ser prefixadas this.
Mesmo que algumas regras sejam aplicadas pela análise de código e pelo StyleCop (como CA1707: Identificadores não devem conter sublinhados vs. SA1310: nomes de campos não devem conter sublinhado ), essas duas ferramentas são complementares e geralmente são usadas lado a lado.
Já temos revisões de código
A presença de revisões de código não é um motivo para evitar a análise de código. A análise de código e o StyleCop são excelentes para encontrar as coisas automaticamente antes de uma revisão de código. Não há nada pior do que passar uma revisão de código identificando problemas de estilo ou padrões problemáticos que poderiam ter sido encontrados automaticamente. Mantenha revisões de código para coisas interessantes.
Outro aspecto é que os revisores humanos não são necessariamente bons em detectar problemas encontrados pela análise de código. Por exemplo, uma instância de uma classe implementada IDisposablepode ser criada em um local e depois descartada em um local diferente. O revisor levará algum tempo para encontrá-lo, enquanto leva apenas alguns milissegundos para que uma ferramenta de análise estática o descubra.
