Segundo o referido JIRA, o status está como "Fixed" e foi implementado na versão 4.1. De fato, se procurarmos no repositório GitHub do Sonar, o arquivo LCOM4Visitor.java não está mais lá...
(trunk/sonar-squid/src/main/java/org/sonar/java/bytecode/visitor/LCOM4Visitor.java)
Bem, vamos ver o que eles disseram:
"In real life projects, this metric generates too many false-positives to be really usable.Traduzindo: "Em projetos da vida real, essa métrica gera muitos falsos-positivos para ser realmente utilizável. Métricas relacionadas com LCOM4 deve ser desativadas também".
LCOM4-related metrics must be deprecated as well"
Eu trabalho com análise de código há muito tempo e, na maioria das vezes em que notei um nível alto de LCOM4, as classes violavam o SRP (Princípio de Responsabilidade Única), e deveriam ser refatoradas. Uns poucos casos (classes exigidas por frameworks, classes de contexto etc) eram justificados e poderiam ficar dessa forma.
E o mais engraçado é que não vi votos (a favor ou contra) nem comentários significativos no JIRA do Sonar. Ou seja, parece que foi uma decisão unilateral, ou, no mínimo, tomada por um pequeno grupo de pessoas. Só que o impacto sobre os usuários poderá ser muito grande.
Onde se basearam para tomar essa decisão? Onde estão as análises estatísticas que a embasaram? Cadê as evidências? Cadê os critérios do processo decisório que os levou a esta atitude? Onde estão as consultas aos usuários, para saber se concordam com isso?
Bem, no mínimo, essa atitude é lamentável e me faz rever o uso e a confiança que tinha nessa ferramenta. Aliás, foi um dos motivos para criarmos o jQana...
Eu não quero emitir opiniões subjetivas e sem embasamento. Só quero trazer a vocês esse fato, para que levem em consideração.
Nenhum comentário:
Postar um comentário