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

StackOverflow https://stackoverflow.com/questions/4080

Pergunta

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 outras)
  • ferramentas de cobertura de código (Cobertura, Emma e quaisquer outras)
  • quaisquer outras ferramentas baseadas em instrumentação
  • qualquer outra coisa, se 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 aos seus IDEs e às ferramentas de construção.

Se uma ferramenta estiver disponível apenas de uma forma específica (como um plugin IDE ou, digamos, um plugin de ferramenta de construção), essa informação também será digna de nota.

Foi útil?

Solução

Para ferramentas de análise estática, costumo usar CPD, PMD, Encontrar Bugs, e Estilo de verificação.

CPD é a ferramenta "Detector de Copiar/Colar" do PMD.Eu estava usando o PMD por um tempo antes de perceber o Link "Encontrando código duplicado" no Página do PMD.

Gostaria de salientar que essas ferramentas às vezes podem ser estendidas além de seu conjunto de regras “prontas para uso”.E não apenas porque são de código aberto para que você possa reescrevê-los.Algumas dessas ferramentas vêm com aplicativos ou “ganchos” que permitem sua extensão.Por exemplo, o PMD vem com o ferramenta "designer" que permite criar novas regras.Além disso, Checkstyle tem o Descendente Token verifique se possui propriedades que permitem uma personalização substancial.

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

Além da simples integração na construção, acho útil configurar as ferramentas para serem um pouco "integradas" de algumas outras maneiras.Ou seja, geração de relatórios e uniformidade de supressão de avisos.Gostaria de adicionar esses aspectos a esta discussão (que provavelmente também deveria ter a tag "análise estática"):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, transformo a saída para que cada aviso tenha um formato simples:

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

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 pelo meu script Ant com Ant cadeias de filtros.

A segunda "integração" que faço é para supressão de avisos.Por padrão, cada ferramenta suporta comentários ou uma anotação (ou ambos) que você pode colocar em seu código para silenciar um aviso que você deseja ignorar.Mas essas diversas solicitações de supressão de aviso não têm uma aparência consistente, o que parece um tanto bobo.Quando você suprime 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 em linhas de código com a string "NOPMD" em um comentário.Além disso, PMD suporta Java @SuppressWarnings anotação.Eu configuro o PMD para usar comentários contendo "SuppressWarning(PMD." em vez de NOPMD para que as supressões de PMD sejam parecidas.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 o "SuppressWarnings(PMD." parte é significativa para um comentário, mas é consistente com o apoio do PMD ao @SuppressWarning anotação que reconhece violações de regras individuais pelo 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 o Checkstyle contêm as strings CHECKSTYLE:OFF e CHECKSTYLE:ON, respectivamente.Alterando esta configuração (com "SuppressionCommentFilter" do Checkstyle) para usar as strings "BEGIN SuppressWarnings(CheckStyle." e "END SuppressWarnings(CheckStyle."faz com que os controles pareçam mais com PMD:

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

Com comentários Checkstyle, a violação de verificação específica (HiddenField) é significativo porque cada cheque tem seu próprio "BEGIN/END"comente par.

FindBugs também suporta supressão de geração de aviso com um @SuppressWarnings anotação, portanto, nenhuma configuração adicional é necessária para atingir algum nível de uniformidade com outras ferramentas.Infelizmente, Findbugs tem que suportar um costume @SuppressWarnings anotação porque o Java integrado @SuppressWarnings anotação tem um SOURCE polí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 conflitos com Java @SuppressWarnings anotação:

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

Essas técnicas fazem com que as coisas pareçam razoavelmente consistentes entre as ferramentas.Observe que cada supressão de aviso contém 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.

Outras dicas

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

EclEmma é um incrível Plugin Eclipse que mostra a cobertura do código colorindo a fonte java no editor (captura de tela) - a cobertura é gerada executando um teste JUnit.Isso é realmente ú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.Isto é muito mais amigável e útil do que gerar um relatório e depois examiná-lo para ver quais classes têm baixa cobertura.

Os plugins Checkstyle e Findbugs Eclipse também são úteis, pois geram avisos no editor conforme 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 números agregados.Eles são gerados por nossas compilações de CI, que são executadas usando Contínuo.

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 nossos builds do 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 seus Projeto Mojo.

Observação:O Clover tem 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 possui.

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

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

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

Estilo de verificação é outro que usei em uma empresa anterior ...serve principalmente para verificação de estilo, mas também pode fazer algumas análises estáticas.Também, Trevo para cobertura de código, mas 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, apoiando o seu desenvolvimento.Infelizmente ainda não está amplamente difundido que essas ferramentas são importantes.

Usamos FindBugs e JDepend integrados ao Ant.Usamos JUnit, mas não usamos 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 elegante quando você executa o javac no console do Windows.:P

Tive boa 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 utiliza PMD e Cobertura, na verdade nossos projetos são 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 plugins para cada projeto.

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

Estrutura 101 é bom em análise de código e em encontrar dependências cíclicas de pacotes.

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

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

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

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

Todos estão integrados ao Maven 1.x em nosso caso e vinculados ao Hudson, que executa nossas compilações no check-in, bem como coisas extras todas as noites e semanalmente.A tendência do 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.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top