Quais ferramentas de análise de código você usa para seus projetos Java? [fechadas]

Quais ferramentas de análise de código você usa em seus projetos Java?

Estou interessado em todos os tipos

• ferramentas de análise de código estático (FindBugs, PMD e quaisquer outros)
• ferramentas de cobertura de código (Cobertura, Emma e quaisquer outras)
• quaisquer outras ferramentas baseadas em instrumentação
• qualquer outra coisa, se eu estiver faltando alguma coisa

Se aplicável, indique também quais ferramentas de construção você usa e quão bem essas ferramentas se integram com seus IDEs e ferramentas de construção.

Se uma ferramenta estiver disponível apenas de uma maneira específica (como um plug-in IDE ou, digamos, um plug-in de ferramenta de construção), essa informação também é digna de nota.

Para ferramentas de análise estática, geralmente uso CPD, PMD , FindBugs e Checkstyle .

CPD é a ferramenta PMD "Copiar / Colar Detector". Eu estava usando o PMD por um tempo antes de notar o link "Finding Duplicated Code" na página do PMD .

Eu gostaria de salientar que essas ferramentas às vezes podem ser estendidas além de seu conjunto de regras "out-of-the-box". E não apenas porque eles são de código aberto para que você possa reescrevê-los. Algumas dessas ferramentas vêm com aplicativos ou "ganchos" que permitem que sejam estendidas. Por exemplo, o PMD vem com a ferramenta "designer" que permite criar novas regras. Além disso, Checkstyle tem a verificação DescendantToken que possui propriedades que permitem uma personalização substancial.

Eu integro essas ferramentas com uma construção baseada no Ant . Você pode seguir o link para ver minha configuração comentada.

Além da integração simples com a construção, acho útil configurar as ferramentas para serem um tanto "integradas" de algumas outras maneiras. Ou seja, geração de relatórios e uniformidade de supressão de avisos. Eu gostaria de adicionar esses aspectos a esta discussão (que provavelmente deveria ter a tag "análise estática" também): como as pessoas estão configurando essas ferramentas para criar uma solução "unificada"? (Eu fiz esta pergunta separadamente aqui )

Primeiro, para relatórios de aviso, eu transformo a saída para que cada aviso tenha o formato simples:

/absolute-path/filename:line-number:column-number: warning(tool-name): message

Isso geralmente é chamado de "formato Emacs", mas mesmo se você não estiver usando o Emacs, é um formato razoável para homogeneizar relatórios. Por exemplo:

/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.

Minhas transformações de formato de aviso são feitas por meu script Ant com filterchains Ant .

A segunda "integração" que faço é para supressão de avisos. Por padrão, cada ferramenta oferece suporte a comentários ou uma anotação (ou ambos) que você pode colocar em seu código para silenciar um aviso que deseja ignorar. Mas essas várias solicitações de supressão de aviso não têm uma aparência consistente, o que parece um tanto bobo. Ao suprimir um aviso, você está suprimindo um aviso, então por que não escrever sempre " SuppressWarning?"

Por exemplo, a configuração padrão do PMD suprime a geração de avisos nas linhas de código com a string " NOPMD" em um comentário. Além disso, o PMD oferece suporte à @SuppressWarningsanotação Java . Eu configuro o PMD para usar comentários contendo " SuppressWarning(PMD." em vez de NOPMDpara que as supressões de PMD sejam semelhantes. Eu preencho a regra específica que é violada ao usar a supressão de estilo de comentário:

// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained

Apenas a SuppressWarnings(PMD.parte " " é significativa para um comentário, mas é consistente com o suporte do PMD para a @SuppressWarninganotação que reconhece violações de regra individuais por nome:

@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended

Da mesma forma, Checkstyle suprime a geração de avisos entre pares de comentários (nenhum suporte de anotação é fornecido). Por padrão, os comentários para ativar e desativar Checkstyle contêm as strings CHECKSTYLE:OFFe CHECKSTYLE:ON, respectivamente. Alterar esta configuração (com "SuppressionCommentFilter" do Checkstyle) para usar as strings " BEGIN SuppressWarnings(CheckStyle." e " END SuppressWarnings(CheckStyle." torna os controles mais parecidos com PMD:

// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)

Com comentários de estilo de verificação, a violação de verificação específica ( HiddenField) é significativa porque cada verificação tem seu próprio BEGIN/ENDpar de comentários " ".

FindBugs também suporta a supressão de geração de aviso com uma @SuppressWarningsanotação, portanto, nenhuma configuração adicional é necessária para atingir algum nível de uniformidade com outras ferramentas. Infelizmente, Findbugs precisa suportar uma @SuppressWarningsanotação customizada porque a @SuppressWarningsanotação Java integrada tem uma SOURCEpolítica de retenção que não é forte o suficiente para reter a anotação no arquivo de classe onde FindBugs precisa dela. Eu qualifico totalmente as supressões de avisos do FindBugs para evitar conflito com a @SuppressWarningsanotação do Java :

@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")

Essas técnicas fazem as coisas parecerem razoavelmente consistentes entre as ferramentas. Observe que ter cada supressão de aviso contendo a string " SuppressWarnings" facilita a execução de uma pesquisa simples para encontrar todas as instâncias de todas as ferramentas em uma base de código inteira.

Eu uso uma combinação de Cobertura, Checkstyle, (Ecl) Emma e Findbugs.

EclEmma é um plugin do Eclipse incrível que mostra a cobertura do código colorindo o código-fonte Java no editor ( captura de tela ) - a cobertura é gerada executando um teste JUnit. Isso é muito útil quando você está tentando descobrir quais linhas são cobertas em uma classe específica ou se deseja ver apenas quais linhas são cobertas por um único teste. Isso é muito mais amigável e útil do que gerar um relatório e depois examinar o relatório para ver quais classes têm baixa cobertura.

Os plug-ins Checkstyle e Findbugs Eclipse também são úteis, pois geram avisos no editor à medida que você digita.

O Maven2 possui plug-ins de relatório que funcionam com as ferramentas acima para gerar relatórios em tempo de construção. Usamos isso para obter relatórios gerais do projeto, que são mais úteis quando você deseja agregar números. Eles são gerados por nossos builds de CI, que são executados usando o Continuum .

Todos os itens a seguir usamos e integramos facilmente em nossas compilações Maven 2.x e Eclipse / RAD 7:

• Teste - JUnit / TestNG
• Análise de código - FindBugs, PMD
• Cobertura de código - Clover

Além disso, em nossas compilações Maven, temos:

• JDepend
• Verificador de tags (TODO, FIXME, etc)

Além disso, se você estiver usando o Maven 2.x, o CodeHaus tem uma coleção de plug-ins úteis do Maven em seu projeto Mojo .

Observação: o Clover possui integração pronta para uso com o servidor Bamboo CI (já que ambos são produtos Atlassian). Existem também plug-ins Bamboo para FindBugs, PMD e CheckStyle, mas, como observado, o servidor Hudson CI gratuito também os tem.

Eu uso a análise estática embutida no IntelliJ IDEA. Integração perfeita.

Eu uso a cobertura de código embutida no Intellij IDEA (baseada no EMMA). Novamente, integração perfeita.

Esta solução integrada é confiável, poderosa e fácil de usar em comparação com ferramentas de montagem de vários fornecedores.

Checkstyle é outro que usei em uma empresa anterior ... é principalmente para verificação de estilo, mas também pode fazer algumas análises estáticas. Além disso, Clover para cobertura de código, embora esteja ciente de que não é uma ferramenta gratuita.

Estamos usando FindBugs e Checkstyle, bem como Clover para cobertura de código.

Acho importante ter algum tipo de análise estática, dando suporte ao seu desenvolvimento. Infelizmente, ainda não é amplamente divulgado que essas ferramentas são importantes.

Usamos FindBugs e JDepend integrados com Ant. Usamos JUnit, mas não estamos usando nenhuma ferramenta de cobertura.

Não o estou usando integrado ao Rational Application Developer (o IDE que estou usando para desenvolver aplicativos J2EE) porque gosto de como fica legal quando você executa o javac no console do Windows. : P

Tive sorte com a Cobertura. É uma ferramenta de cobertura de código que pode ser executada por meio de seu script Ant como parte de sua construção normal e pode ser integrada ao Hudson.

Nossa equipe usa PMD e Cobertura, na verdade nossos projetos são projetos maven e é muito simples incluir plug-ins para análise de código. A verdadeira questão seria para um projeto específico qual análise você precisa usar, minha opinião é que você não poderia usar os mesmos plug-ins para cada projeto.

em nosso projeto usamos Sonar na frente do checkstyle, pmd .... junto com o CI (Bamboo, Hudson) temos também um bom histórico de nossa qualidade de fonte e direcionamento que fazemos. Eu gosto do Sonar, porque você é uma ferramenta central no CI Stack que faz isso por você, e você pode personalizar facilmente as regras para cada projeto.

A Estrutura 101 é boa para análise de código e localização das dependências cíclicas do pacote.

Estou procurando muitas respostas para aprender sobre novas ferramentas e consolidar esse conhecimento em uma pergunta / tópico, então duvido que haja uma resposta verdadeira para essa pergunta.

Minha resposta à minha própria pergunta é que usamos:

• Findbugs para procurar erros comuns de má / codificação - execute do maven e também se integra facilmente ao Eclipse
• Cobertura para nossos relatórios de cobertura - executado a partir de maven

Hudson também possui um plugin de varredura de tarefas que irá mostrar uma contagem de seus TODO e FIXMEs, bem como mostrar onde eles estão nos arquivos fonte.

Todos são integrados ao Maven 1.x em nosso caso e vinculados ao Hudson, que executa nossas compilações no check-in, bem como atividades extras noturnas e semanais. A tendência de Hudson representa graficamente nossos testes JUnit, cobertura, findbugs, bem como tarefas abertas. Há também um plugin Hudson que relata e representa graficamente nossos avisos de compilação. Também temos vários testes de desempenho com seus próprios gráficos de desempenho e uso de memória ao longo do tempo usando o plugin Hudson plots.