Microsoft Source Analyzer (stylecop) VS Microsoft Code Analysis (fxcop)

Publicado: 28/06/2008 em Quality Assurance

Eae pessoal como vão? Dando continuidade aos tópicos sobre Quality Assurance, mais especificamente sobre as novidades do recém lançado Source Analyzer for C#, vou publicar para vocês um email trocado internamente na empresa que trabalho onde eu respondo algumas dúvidas levantadas, elas mostram algumas comparações entre o modelo do já consagrado Code Analysis, opinem a respeito

 

1 – É essencial que funcione no VS2005. Se considerarmos o CISFarma, acabamos de padronizar tudo no 2005, pois ainda havia um laboratório com o 2003. Ainda vamos “ter que conviver” com ele por um bom tempo;
Ele funciona no Visual Studio 2005 também segundo descrição do post de lançamento da ferramenta (http://blogs.msdn.com/sourceanalysis/archive/2008/05/23/announcing-the-release-of-microsoft-source-analysis.aspx )

Sobre a questão de ser necessário utilizar o 2005 ao invés do 2008, acredito que seja possível padronizar a utilização do 2008, pois ele suporta o 2005 e suas versões de framework, o que não obriga-nos à desenvolver com C# 3.0 por exemplo, diferentemente do que aconteceu com o VS 2003 e 2005 que a ferramenta era atrelada às versões de framework. Existe algum motivo especial para manter o VS 2005?

2 – Além da diferença de analisar o código-fonte e não o compilado, tem alguma outra coisa? As regras são as mesmas? Ou só tem mais regras?

Como podem ver na imagem abaixo as regras são novas e podemos inclusive observar novas categorias e uma organização maior dentro das categorias principais, vide Layout Rules.

clip_image002

3 – As regras não são antagônicas? Não corremos o risco de atender as regras de um e, por conta disso, não atender as regras do outro?

Tendo em vista que as regras não são as mesmas podemos ter conflitos entre elas sim, cabe escolhermos um caminho, ou estilo, a seguir.

Como pode-se ver o Source Analyzer é um modelo bem moderno de codificação com foco na clareza, não existe nada a respeito, mas possivelmente ele pode substituir o CA. Não faz muito sentido os dois caminharem separados e conflitantes, e a vantagem do SA é que ele analisa o que os humanos escrevem, que é realmente o problema e da pra se prever otimizações e comportamentos do compilador através do que nós escrevemos, já o caminho contrário, analizar a MSIL gerada não da uma visão ampla do que era o código.

4 É flexível com o Code Analysis, no qual podemos habilitar as regras aos poucos e classificá-las com níveis diferentes de criticidade?

O SA tem uma janela própria para exibir suas mensagens de inconformidades no código, ele não está integrado até o momento à janela de erros e warnings do Visual Studio, sendo assim ele não interrompe o build, apenas avisa, vejam a imagem

clip_image004

5 – Tem relatórios, como o Code Analysis, para que possamos apurar a evolução da qualidade do código entregue pelas equipes ao longo do tempo?

Sim, ele gera dentro da pasta raiz do projeto o arquivo SourceAnalysisViolations.xml, o qual está em anexo para que vocês avaliem.

Ainda não vi todas as suas regras com calma, mas o que já vi apresenta regras de codificação mais interessantes do que as dos Guidelines da Microsoft, das quais eu eu descordava em alguns pontos.Acredito que valha a pena observar esta ferramenta com mais atenção pois pode ser muito útil

Abraços

Divirtam-se e escrevam elegamente com a nova ferramenta, as equipes de análise de código e o software agradecem 😀

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s