Que ferramentas de análise de código que você usa para seus projetos Java?

votos
107

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

Estou interessado em todos os tipos

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

Se for o caso, também afirmam que construir ferramentas que você usa e como essas ferramentas de integração com ambas as IDEs e construir ferramentas.

Se uma ferramenta está disponível apenas uma maneira específica (como um plugin do IDE, ou, digamos, um plugin ferramenta de construção) que a informação também é digno de nota.

Publicado 06/08/2008 em 23:45
fonte usuário
Em outras línguas...                            


12 respostas

votos
66

Para ferramentas de análise estática Costumo usar CPD, PMD , FindBugs , e Checkstyle .

CPD é o PMD "copiar / colar Detector" ferramenta. Eu estava usando PMD para um pouco antes de eu observei o link "Finding código duplicado" na página web PMD .

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

I integrar estas ferramentas com uma compilação com base no Ant . Você pode seguir o link para ver a minha configuração comentou.

Além da simples integração na construção, acho que é útil para configurar as ferramentas para ser um pouco "integrados" em um par de outras maneiras. Ou seja, geração de relatórios e alerta supressão uniformidade. Eu gostaria de adicionar estes aspectos a esta discussão (o que provavelmente deve ter a etiqueta "-análise estática" também): como é que as pessoas configurar essas ferramentas para criar uma solução "unificado"? (Eu já fiz esta pergunta separadamente aqui )

Primeiro, para relatórios de alerta, eu transformar a saída de modo que cada aviso tem o formato simples:

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

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

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

Meus transformações formato de alerta são feitas pelo meu script Ant com formiga filterchains .

O segundo "integração" que eu faço é para a supressão de alerta. Por padrão, cada ferramenta suporta comentários ou uma anotação (ou ambos) que você pode colocar no seu código para silenciar um aviso de que você deseja ignorar. Mas estes vários pedidos de supressão de aviso não têm uma aparência consistente que parece um pouco bobo. Quando você está suprimindo um aviso, você está suprimindo um aviso, então por que não escrevo sempre " SuppressWarning?"

Por exemplo, a configuração padrão do PMD suprime geração de advertência em linhas de código com a string " NOPMD" em um comentário. Além disso, PMD suporta Java @SuppressWarningsanotação. Eu configurar PMD usar comentários que contenham " SuppressWarning(PMD." em vez de NOPMDmodo que supressões PMD parecidos. Eu preencher a regra particular que é violado quando se utiliza a supressão estilo de comentário:

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

Somente a " SuppressWarnings(PMD.parte" é significativo para um comentário, mas é consistente com o apoio da PMD para a @SuppressWarninganotação que reconhece violações de regras individuais pelo nome:

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

Da mesma forma, Checkstyle suprime geração de alerta entre os pares de comentários (sem suporte anotação é fornecido). Por padrão, os comentários de transformar Checkstyle e desligando conter as cordas CHECKSTYLE:OFFe CHECKSTYLE:ON, respectivamente. Mudando esta configuração (com "SuppressionCommentFilter" do Checkstyle) para usar as cordas " BEGIN SuppressWarnings(CheckStyle." e " END SuppressWarnings(CheckStyle." torna os controles parecem 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 cheque especial ( HiddenField) é significativo porque cada verificação tem o seu próprio " BEGIN/END" comentário par.

FindBugs também suporta a geração de supressão de aviso com uma @SuppressWarningsanotação, então nenhuma configuração adicional é necessário para atingir um certo nível de uniformidade com outras ferramentas. Infelizmente, Findbugs tem de suportar um costume @SuppressWarningsanotação porque o Java embutido @SuppressWarningsanotação tem uma SOURCEpolítica de retenção que não é forte o suficiente para manter a anotação no arquivo de classe, onde FindBugs precisa. I qualificar totalmente FindBugs avisos supressões para evitar colidir com Java @SuppressWarningsanotação:

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

Estas técnicas faz as coisas parecerem razoavelmente consistente em ferramentas. Note-se que ter cada supressão de aviso conter a string " SuppressWarnings" faz com que seja fácil de executar uma pesquisa simples para encontrar todas as instâncias para todas as ferramentas através de uma base de código inteiro.

Respondeu 17/09/2008 em 05:02
fonte usuário

votos
16

I usar uma combinação de Cobertura, Checkstyle, (ECL) Ema e Findbugs.

EclEmma é uma incrível plugin do Eclipse que mostra a cobertura de código colorindo a fonte java no editor ( captura de tela ) - a cobertura é gerada pela execução de um teste JUnit. Isto é realmente útil quando você está tentando descobrir quais linhas são cobertos em uma classe particular, ou se você quiser ver apenas as linhas que são cobertos por um único teste. Isso é muito mais amigável e útil do que gerar um relatório e, em seguida, olhando através do relatório para ver quais classes têm baixa cobertura.

Os plugins checkstyle e Findbugs Eclipse também são úteis, eles geram avisos no editor enquanto você digita.

Maven2 tem plugins relatório que trabalham com as ferramentas acima para gerar relatórios em tempo de compilação. Nós usamos isso para obter relatórios de projetos globais, que são mais úteis quando você quer números agregados. Estas são geradas pelo nosso CI constrói, que funcionam utilizando Continuum .

Respondeu 29/10/2008 em 19:55
fonte usuário

votos
11

Todas as seguintes usamos e integrar easiy tanto no nosso 2.x Maven constrói e Eclipse / RAD 7:

  • Testing - JUnit / TestNG
  • análise de código - FindBugs, PMD
  • cobertura de código - Clover

Além disso, em nossa Maven constrói temos:

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

Além disso, se você estiver usando Maven 2.x, Codehaus tem uma coleção de acessível plugins Maven em seu projeto Mojo .

Nota: Clover tem integração out-of-the-box com o servidor Bamboo CI (uma vez que ambos são produtos Atlassian). Existem também plugins de bambu para FindBugs, PMD, e CheckStyle mas, como observado, o servidor Hudson CI livre tem os demais.

Respondeu 16/08/2008 em 19:48
fonte usuário

votos
8

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

Eu uso a cobertura de código embutido no IntelliJ IDEA (baseado em EMMA). Novamente, perfeita integração.

Esta solução integrada é de confiança, poderoso e fácil de usar em comparação com reunindo ferramentas de vários fornecedores.

Respondeu 17/09/2008 em 15:40
fonte usuário

votos
4

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

Respondeu 07/08/2008 em 08:18
fonte usuário

votos
3

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

Eu acho que é importante ter algum tipo de análise estática, apoiando o seu desenvolvimento. Infelizmente é ainda não muito difundida de que essas ferramentas são importantes.

Respondeu 07/08/2008 em 08:21
fonte usuário

votos
1

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

Respondeu 17/09/2011 em 07:59
fonte usuário

votos
1

em nosso projeto usamos Sonar em frente checkstyle, pmd .... juntamente com a CI (Bambu, Hudson) temos também uma boa história de nossa qualidade fonte eo que direção vamos nós. Eu gosto Sonar, porque você uma ferramenta central na Stack CI que faz isso para você, e você pode fácil personalizar as regras para cada projeto.

Respondeu 29/08/2010 em 10:56
fonte usuário

votos
1

Nosso uso equipe PMD e Cobertura, na verdade, nossos projetos são projetos Maven e há muito simples para incluir plug-ins para análise de código. A questão real seria para projeto específico que a análise que você precisa usar, a minha opinião é que é que você não poderia usar os mesmos plugins para cada projeto.

Respondeu 17/09/2008 em 15:46
fonte usuário

votos
1

Eu tive sorte com Cobertura. É uma ferramenta de cobertura de código que pode ser executado através de seu script ant como parte de sua construção normal e pode ser integrado em Hudson.

Respondeu 17/09/2008 em 05:31
fonte usuário

votos
1

Usamos FindBugs e JDepend integrado com Ant. Nós usamos JUnit, mas não estamos usando qualquer ferramenta de cobertura.

Eu não estou usando integrado ao Rational Application Developer (IDE que estou usando para desenvolver aplicações J2EE), porque eu gosto de como puro que parece quando você executar javac no console do Windows. : P

Respondeu 07/08/2008 em 01:20
fonte usuário

votos
0

Estou à procura de muitas respostas para aprender sobre novas ferramentas e consolidar esse conhecimento em uma pergunta / thread, por isso duvido que haverá uma verdadeira resposta a esta pergunta.

Minha resposta à minha pergunta é que nós usamos:

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

Hudson também tem um plugin tarefa-scanner que irá exibir uma contagem de seu TODO e FIXMEs, bem como mostrar onde eles estão nos arquivos de origem.

Todos são integrados com Maven 1.x no nosso caso e amarrado em Hudson, que corre o nosso constrói no check-in, bem como coisas extra noturno e semanal. Hudson tendência gráficos nossos testes JUnit, cobertura, findbugs, bem como tarefas abertas. Há também um plugin Hudson que relatórios e gráficos nossos avisos de compilação. Temos também vários testes de desempenho com seus próprios gráficos de desempenho e uso de memória ao longo do tempo, utilizando as parcelas Hudson plugins também.

Respondeu 08/08/2008 em 15:53
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more