Pergunta

Estamos a introduzir ferramentas de análise estática para o sistema de compilação para o nosso Java produto.Estamos usando o Maven2 assim Checkstyle e PMD integração de vir de graça.No entanto parece que há uma grande sobreposição na funcionalidade entre essas duas ferramentas, em termos de cumprimento de regras de estilo.

Há um benefício da utilização de ambas desses?Eu não quero manter 2 ferramentas se vai trabalhar.Se podemos escolher uma, o que devemos usar, e por quê?

Estamos também planejando usar FindBugs.Existem outras ferramentas de análise estática devemos olhar?

Atualização: O consenso parece ser de que a PMD é preferível CheckStyle.Eu não vejo uma razão sólida para o uso de ambos, e eu não quero manter 2 conjuntos de arquivos de regra, então provavelmente iremos apontar para o PMD exclusivamente.Também estaremos trazendo FindBugs, e talvez, eventualmente, Macker para impor arquitetônico regras.

Foi útil?

Solução

Você deve definitivamente usar FindBugs.Na minha experiência, a taxa de falso-positivo é muito baixa, e mesmo os menos críticos avisos relatórios vale a pena abordar, em certa medida.

Como para Checkstyle vs.PMD, eu não usaria Checkstyle, pois está muito preocupado apenas com estilo.Na minha experiência, Checkstyle apresentará um relatório sobre uma tonelada de coisas que são completamente irrelevantes.PMD, por outro lado, também é capaz de apontar questionáveis práticas de codificação e a sua saída é geralmente mais relevante e útil.

Outras dicas

Ambos os softwares são úteis. Checkstyle o ajudará durante sua programação, verificando o seu estilo de codificação ou seja, aparelhos, nomeando etc. coisas simples, mas muito numerosas!

O PMD o ajudará, verificando regras mais complicadas, como durante o design de suas classes ou para problemas mais especiais, como implementar corretamente a função clone. Simplesmente, o PMD verificará o seu estilo de programação

No entanto, ambos os softwares sofrem de regras semelhantes às vezes explicadas. Com uma configuração ruim, você pode verificar as coisas duas ou duas coisas opostas, ou seja, "remover construtores inúteis" e "sempre um construtor".

Se escolhermos um, qual devemos usar e por quê?

Essas ferramentas não estão competindo, mas são complementares e devem ser usadas simultaneamente.

O tipo de convenção (estilo de verificação) é a cola que permite que as pessoas trabalhem juntas e liberte sua criatividade, em vez de gastar tempo e energia para entender o código inconsistente.

Exemplos de estilo de seleção:

  • Existe javadoc nos métodos públicos?
  • O projeto está após as convenções de nomeação do sol?
  • O código está escrito com um formato consistente?

Enquanto o PMD lembra as más práticas:

  • Pegando uma exceção sem fazer nada
  • Tendo código morto
  • Muitos métodos complexos
  • Uso direto das implementações em vez de interfaces
  • Implementando o método hashcode () sem o método não é igual (objeto)

fonte:http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-climplementary/

Usamos os dois:

  • Checkstyle para garantir que todos na equipe escrevam código em um Maner semelhante
  • PMD para encontrar áreas de código problemáticas e próximas metas de refatoração

Se o seu principal local de uso estiver no desenvolvimento do Eclipse, o CodePro das instanciações será o melhor. Anteriormente, era uma ferramenta comercial, mas agora o Google comprou instanciações, então o CodePro AnalyTix está gratuito agora.

Verificação de saída http://code.google.com/javadevtools/download-codepro.html

Se você revisou listas de regras de estilo de seleção, PMD e FindBugs, você viu que todos os três fornecem saída valiosa e todos os três sobrepostos e também trazem suas próprias regras exclusivas para a tabela. É por isso que ferramentas como o sonar usam os três.

Dito isto, o FindBugs possui as regras mais específicas ou de nicho (por exemplo, "captura duvidosa de ilegalMonitorStateException" - com que frequência você provavelmente encontrará isso?), Por isso, é utilizável com pouca ou nenhuma configuração e seus avisos devem ser levados a sério. Com o estilo de seleção e o PMD, as regras são mais gerais e relacionadas ao estilo, para que elas sejam usadas apenas com arquivos de configuração personalizados para poupar a equipe de uma avalanche de feedback irrelevante ("TAB CHAR na linha 5", "TAB CHAR na linha 6", "Tab Char na linha 7" ... você entendeu). Eles também fornecem ferramentas poderosas para escrever suas próprias regras avançadas, por exemplo, o estilo de seleção DescendentToken regra.

Ao usar os três (especialmente com uma ferramenta como o sonar), todos eles devem ser configurados separadamente (leva pelo menos alguns dias para cobrir todas as regras) enquanto prestava atenção para evitar a duplicação (todas as três ferramentas detectam que o hashcode () foi substituído e iguais () não, por exemplo).

Em resumo, se você considerar a análise de código estático valioso, rejeitar o valor que qualquer um dos três fornece não faz sentido, mas para usar os três, você precisa investir tempo para configurá -los para fornecer feedback utilizável.

O Sonar (http://www.sonarsource.org/) é uma plataforma aberta muito útil para gerenciar a qualidade do código e inclui estilo de seleção, PMD, findbugs e muito mais.

Isso também indica que todas as três ferramentas têm seu direito de existir ...

Checkstyle e PMD são bons em verificar os padrões de codificação e são fáceis de estender. Mas o PMD possui regras adicionais para verificar a complexidade ciclomática, a complexidade do nPath, etc., o que permite escrever um código saudável.

Outra vantagem do uso do PMD é o CPD (detector de cópia/pasta) .Is descobre a duplicação de código em projetos e não é restringida ao Java.it também trabalha para o JSP. Neal Ford tem uma boa apresentação em Métricas impulsionadas pelo desenvolvimento ágil, que fala sobre muitas ferramentas que são úteis para o desenvolvimento Java/Java EE

Acho que o CheckStyle e o PMD são melhores para aplicar problemas de estilo e bugs simples de codificação óbvia. Embora tenha descoberto que gosto de usar o Eclipse e todos os avisos, isso fornece melhor para esse fim. Afilamos as coisas usando preferências compartilhadas e marcando -as como erros reais. Dessa forma, eles nunca são verificados em primeiro lugar.

O que eu recomendo fortemente e entusiasticamente é usar o FindBugs. Como funciona no nível do bytecode, pode verificar as coisas impossíveis no nível da fonte. Embora cospe sua parte justa de lixo, encontrou muitos bugs reais e importantes em nosso código.

Ambas as ferramentas são configuráveis e podem fazer praticamente as mesmas coisas.O que disse, se estamos falando de out-of-the-box", há uma grande quantidade de sobreposição, mas há regras distintas/verifica bem.Por exemplo, Checkstyle tem forte suporte para verificar Javadoc e encontrar números mágicos, para citar alguns.Além disso, Checkstyle tem um "controle de importação" recurso semelhante à funcionalidade de Macker (eu não usado Macker).

Se há coisas que são importantes para você que Checkstyle faz out-of-the-box que PMD não, você pode considerar um mínimo de Checkstyle configuração apenas com os cheques.Em seguida, instituir uma política de que o Checkstyle de configuração não é possível crescer, basta remover verificações de como implementar uma funcionalidade semelhante com, digamos, personalizada PMD regras.

Considere também que, se você decidir que o Checkstyle "importar" controle de recurso de cobre o que você queria de Macker, em seguida, você pode implementar PMD/Checkstyle em vez de PMD/Macker.De qualquer forma, é duas ferramentas, mas com Checkstyle, você teria que obter as coisas que PMD não faz out-of-the-box "de graça".

Um ponto que eu não vi até agora é que existem plugins para IDEs que aplicarão os conjuntos de regras do estilo de seleção no seu código, enquanto os plugins PMD relatarão apenas violações. Por exemplo, em um projeto de vários locais em várias equipes de programação, é importante aplicar ativamente os padrões, em vez de apenas relatar sobre elas.

Ambas as ferramentas têm plug -ins disponíveis para Intellij, NetBeans e Eclipse (na minha opinião, isso cobre o maior uso). Não estou tão familiarizado com o NetBeans, então só posso comentar sobre Intellij e Eclipse.

De qualquer forma, os plugins PMD para Intellij e Eclipse gerarão relatórios sob demanda Sobre violações do PMD na base de código do projeto.

Os plugins de estilo de seleção, por outro lado, destacarão violações em tempo real e podem (pelo menos para o Intellij, tenho menos experiência com o eclipse) será configurada para converter automaticamente alguns problemas (por exemplo, para 'onestatementPerline', colocará CR-LF Entre as declarações, para 'Needbraces', adicionará aparelhos onde estão ausentes, etc.). Obviamente, apenas as violações mais simples podem ser corrigidas automaticamente, mas ainda é uma ajuda em projetos legados ou projetos localizados em vários locais.

'On Demand' para PMD significa que o desenvolvedor deve decidir conscientemente executar o relatório. Enquanto as violações do estilo de verificação são relatadas automaticamente a eles à medida que se desenvolvem. Enquanto pmd faz Conter um conjunto de regras mais extenso, na minha opinião, o execução/relatório automático de violações em IDES vale o aborrecimento de manter 2 conjuntos de regras.

Portanto, para todos os projetos em que trabalho, usamos as duas ferramentas, o estilo de seleção imposto no IDE, relatou o PMD no IDE, e Ambas relatado e medido em construções (através de Jenkins).

E 10 anos depois ... Em 2018, uso todos eles, PMD e FindBugs.

Começar com FindBugs. Talvez adicione PMD e Checkstyle mais tarde.

Nunca aplique cegamente as regras padrão !

Passos:

  • Execute uma ferramenta com regras padrão em um projeto que tem muito código
  • Adapte as regras a este projeto, comente regras inúteis com algumas notas
  • Concentre -se nas regras de frutas suspensas baixas (NPE, verificações de logger, verificações de recursos não fechadas, ...)
  • Realize algumas correções para regras que você encontra a pena (uma de cada vez!)
  • Faça isso para cada ferramenta, mas não de uma só vez!
  • repita esse processo

Idealmente, cada projeto pode ter regras separadas. Gosto de executar as regras através da compilação (via plug -ins Maven) e falhar nos erros de regra quando souber que um projeto passa por todas as regras que defini. Isso força os desenvolvedores a agirem, porque relatar não é suficiente. A partir desse ponto, seu projeto é praticamente à prova de balas e você pode até adicionar mais regras posteriormente e/ou escrever regras personalizadas.

Dar uma olhada em ulice-ma-maven-plugin Isso combina o estilo de seleção, o PMD, o FindBugs e alguns outros analisadores estáticos, e pré-configura-os. A beleza dessa combinação é que você não precisa configurá -los individualmente em todos os projetos:

<plugin>
  <groupId>com.qulice</groupId>
  <artifactId>qulice-maven-plugin</artifactId>
  <version>0.15</version>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Eu ecoando o comentário de que o PMD é o produto mais atual para verificação de estilo/convenção Java. Com relação ao FindBugs, muitos grupos de desenvolvimento comercial estão usando a cobertura.

Acabei de começar a usar o estilo de verificação e o PMD. Para mim, o PMD é mais fácil de criar regras personalizadas para coisas de modo que existam System.GC (), Runtime.GC (), desde que você possa escrever a consulta XPath, que também não é difícil. No entanto, o PMD não me mostrou que tem o recurso para mostrar o número da coluna. Então, para coisas como os limites da coluna de verificação. Você gostaria de usar o estilo de verificação.

PMD é o que acho mais pessoas me referindo. O Checkstyle era o que as pessoas estavam se referindo a 4 anos atrás, mas acredito que o PMD é mantido mais continuamente e com o que outros IDEs/plugins optam por trabalhar.

O PMD é a melhor ferramenta quando se compara com os estilos de seleção. O Checkstyles pode não ter a capacidade de analisar o código, enquanto o PMD oferece muitos recursos para fazê -lo! O PMD do Off -Course não divulgou regras para Javadoc, comentários, recortes e etc. e, a propósito, estou planejando implementar essas regras ..... Thanx

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