java - Checkstyle vs. PMD

static-analysis findbugs

Question

Estamos introduciendo herramientas de análisis estático en el sistema de compilación para nuestro producto Java. Estamos utilizando Maven2 para que la integración de Checkstyle y PMD gratuita. Sin embargo, parece que hay una gran superposición de funcionalidad entre estas dos herramientas, en términos de imponer reglas de estilo básicas.

¿Hay algún beneficio de utilizar ambos? No quiero mantener 2 herramientas si una funcionará. Si elegimos uno, ¿cuál deberíamos usar y por qué?

También estamos planeando usar FindBugs. ¿Hay otras herramientas de análisis estático que deberíamos mirar?

Actualización: El consenso parece ser que PMD es preferible a CheckStyle. No veo una razón sólida para usar ambos, y no quiero mantener 2 conjuntos de archivos de reglas, por lo que probablemente apuntemos exclusivamente al PMD. También introduciremos FindBugs y, tal vez, eventualmente, Macker para hacer cumplir las reglas de la arquitectura.

Answer 1

Si elegimos uno, ¿cuál deberíamos usar y por qué?

Estas herramientas no compiten, pero son complementarias y deben usarse simultáneamente.

El tipo de convención (Checkstyle) es el pegamento que permite a las personas trabajar juntas y liberar su creatividad en lugar de gastar tiempo y energía para comprender el código inconsistente.

Ejemplos de estilo de control:

• ¿Hay javadoc en métodos públicos?
• ¿Sigue el proyecto las convenciones de nombres de Sun?
• ¿El código está escrito con un formato consistente?

mientras que PMD te recuerda malas prácticas:

• Capturando una excepción sin hacer nada
• Tener un código muerto
• Demasiados métodos complejos
• Uso directo de implementaciones en lugar de interfaces
• Implementando el método hashcode () sin el método no igual (objeto Object)

fuente: http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/

Answer 2

Ambas herramientas son configurables y pueden hacer casi las mismas cosas. Dicho esto, si hablamos de cosas listas para usar, hay una gran coincidencia, pero también hay reglas / controles distintos. Por ejemplo, Checkstyle tiene un soporte más sólido para verificar Javadoc y encontrar números mágicos, por nombrar algunos. Además, Checkstyle tiene una función de "control de importación" que se parece a la funcionalidad de Macker (no he usado Macker).

Si hay cosas que son importantes para usted que Checkstyle hace de fábrica que PMD no lo hace, puede considerar una configuración mínima de Checkstyle con solo esas comprobaciones. Luego establezca una política para que la configuración de Checkstyle no pueda crecer, simplemente elimine las verificaciones a medida que implementa funcionalidades similares con, digamos, reglas de PMD personalizadas.

Además, tenga en cuenta que si decide que la función "control de importación" de Checkstyle cubre lo que quería de Macker, entonces podría implementar PMD / Checkstyle en lugar de PMD / Macker. De cualquier manera, son dos herramientas, pero con Checkstyle, obtendría las cosas que el PMD no hace de inmediato "de forma gratuita".

Answer 3

Ambos softwares son útiles. Checkstyle te ayudará durante tu programación verificando tu estilo de codificación, por ejemplo, frenillos, nombres, etc. ¡Cosas simples pero muy numerosas!

PMD lo ayudará a verificar reglas más complicadas, como durante el diseño de sus clases, o para problemas más especiales, como implementar correctamente la función de clonación. Simplemente, PMD revisará tu estilo de programación

Sin embargo, ambos softwares sufren de reglas similares a veces mal explicadas. Con una configuración incorrecta, puede verificar las cosas dos o dos cosas opuestas, es decir, "Eliminar constructores inútiles" y "Siempre un constructor".

Answer 4

Checkstyle y PMD son buenos para verificar los estándares de codificación y son fáciles de extender. Pero el PMD tiene reglas adicionales para verificar la complejidad ciclomática, la complejidad de Npath, etc. que le permite escribir un código saludable.

Otra ventaja de usar PMD es CPD (Detector de Copiar / Pegar). Encuentra la duplicación de código en los proyectos y no está restringida a JAVA. También funciona para JSP. Neal Ford tiene una buena presentación sobre Metrics Driven Agile Development , que habla de muchas herramientas que son útiles para el desarrollo de Java / Java EE

Answer 5

Definitivamente deberías usar FindBugs . En mi experiencia, la tasa de falsos positivos es muy baja, e incluso las advertencias menos críticas que informa merecen abordarse en cierta medida.

En cuanto a Checkstyle vs. PMD, no usaría Checkstyle ya que solo se trata de estilo. En mi experiencia, Checkstyle informará sobre una tonelada de cosas que son completamente irrelevantes. PMD por otro lado también es capaz de señalar prácticas de codificación cuestionables y su resultado es generalmente más relevante y útil.

Answer 6

Eche un vistazo a qulice-maven-plugin que combina Checkstyle, PMD, FindBugs y algunos otros analizadores estáticos, y los preconfigura. La belleza de esta combinación es que no necesita configurarlos individualmente en cada proyecto:

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

Answer 7

El PMD es a lo que me parece que se refieren más personas. Checkstyle era a lo que la gente se refería hace 4 años, pero creo que el PMD se mantiene de forma más continua y con qué otros IDE / complementos eligen trabajar.

Answer 8

Me gustaría hacerme eco del comentario de que el PMD es el producto más actual para la comprobación de estilo / convención de Java. Con respecto a FindBugs, muchos grupos de desarrollo comercial están usando Coverity.

Answer 9

Me parece que Checkstyle y PMD son los mejores para imponer problemas de estilo y simples errores obvios de codificación. Aunque descubrí que me gusta usar Eclipse y todas las advertencias que proporciona, mejor para ese propósito. Hacemos cumplir las cosas al usar preferencias compartidas y marcarlas como errores reales. De esa manera, nunca se registran en primer lugar.

Lo que recomendaría de manera enérgica y entusiasta es utilizar FindBugs. Como funciona en el nivel de código de bytes, puede verificar cosas que son imposibles en el nivel de origen. Mientras escupe su parte justa de juncos, ha encontrado muchos errores reales e importantes en nuestro código.

Answer 10

PMD es la mejor herramienta cuando se compara con checkstyles. ¡Es posible que Checkstyles no tenga la capacidad de analizar el código mientras que el PMD ofrece muchas funciones para hacerlo! Offcourse PMD no ha publicado las reglas para javadoc, comentarios, sangrías, etc. Y, por cierto, estoy planeando implementar estas reglas ....... gracias

Answer 11

Recién comencé a usar Checkstyle y PMD. Para mí, PMD es más fácil de crear reglas personalizadas para cosas tales que si existe System.gc (), Runtime.gc (), siempre que pueda escribir la consulta XPath que tampoco es difícil. Sin embargo, el PMD no me ha mostrado que tiene la función de mostrar el número de columna. Entonces, para cosas como verificar límites de columna. Es posible que desee utilizar Checkstyle.

Answer 12

Si revisó las listas de reglas de Checkstyle, PMD y Findbugs, habrá visto que las tres proporcionan una salida valiosa y las tres se superponen a un grado y también traen sus propias reglas únicas a la mesa. Es por eso que herramientas como Sonar usan los tres.

Dicho esto, Findbugs tiene las reglas más específicas o de nicho (por ejemplo, "Captura dudosa de IllegalMonitorStateException", ¿con qué frecuencia es probable que te encuentres?) Por lo que se puede utilizar con poca o ninguna configuración y sus advertencias deben tomarse en serio. Con Checkstyle y PMD, las reglas son más generales y están relacionadas con el estilo, por lo que solo deben usarse con archivos de configuración personalizados para evitar una avalancha de comentarios irrelevantes ("Tab char en línea 5", "Tab char en línea 6", "Tab char en la línea 7" ... entiendes la imagen). También proporcionan herramientas poderosas para escribir sus propias reglas avanzadas, por ejemplo, la regla Checkstyle DescendentToken .

Al usar los tres (especialmente con una herramienta como Sonar), todos ellos deben configurarse por separado (toma al menos unos días para cubrir todas las reglas) mientras se presta atención para evitar la duplicación (las tres herramientas detectan que hashCode () ha sido anulado e igual () no, por ejemplo).

En resumen, si considera que el análisis de código estático es valioso, rechazar el valor que cualquiera de los tres proporciona no tiene sentido, pero para usar los tres, debe invertir tiempo para configurarlos y así obtener retroalimentación utilizable.

Answer 13

Si su principal lugar de uso es mientras se desarrolla en eclipse, entonces CodePro de Instantiations será lo mejor. Anteriormente era una herramienta comercial, pero ahora Google compró Instanciaciones para que CodePro analytix ahora sea gratuito.

Consulte http://code.google.com/javadevtools/download-codepro.html

Answer 14

Sonar (http://www.sonarsource.org/) es una plataforma abierta muy útil para administrar la calidad del código, e incluye Checkstyle, PMD, Findbugs y mucho más.

Esto también indica que las 3 herramientas tienen derecho a existir ...

Answer 15

Un punto que no he visto hasta ahora es que haya complementos para los IDE que impongan los conjuntos de reglas CheckStyle en su código, mientras que los complementos de PMD solo informarán sobre las violaciones. Por ejemplo, en un proyecto de múltiples sitios a través de varios equipos de programación, es importante hacer cumplir las normas activamente, en lugar de simplemente informar sobre ellas.

Ambas herramientas tienen complementos disponibles para IntelliJ, NetBeans y Eclipse (en mi opinión, esto cubre la mayor parte del uso). No estoy tan familiarizado con NetBeans, así que solo puedo comentar sobre IntelliJ y Eclipse.

De todos modos, los complementos de PMD para IntelliJ y Eclipse generarán informes bajo demanda sobre violaciones de PMD dentro de la base de código del proyecto.

Los complementos CheckStyle, por otro lado, resaltarán las violaciones sobre la marcha, y pueden (al menos para IntelliJ, tengo menos experiencia con Eclipse) configurarse para convertir automáticamente algunos problemas (por ejemplo, para ''OneStatementPerLine'', colocarán CR-LF entre las declaraciones, para ''NeedBraces'', agregará llaves cuando falten, etc.). Obviamente, solo las violaciones más simples pueden corregirse automáticamente, pero sigue siendo una ayuda para proyectos heredados o proyectos ubicados en varias ubicaciones.

''On demand'' para PMD significa que el desarrollador debe decidir conscientemente ejecutar el informe. Mientras que las infracciones del estilo de control se informan automáticamente a medida que se desarrollan. Si bien el PMD contiene un conjunto de reglas más extenso, en mi opinión, el enfoque / informe automático de las violaciones en los IDE justifica la molestia de mantener 2 conjuntos de reglas.

Entonces, para cualquier proyecto en el que trabaje, utilizamos ambas herramientas, Checkstyle forzado en el IDE, PMD reportado en el IDE, y reportado y medido en versiones (a través de Jenkins).

Answer 16

Usamos ambos:

• Checkstyle para asegurarse de que todos en el equipo escriban código de forma similar
• PMD para encontrar áreas de código problemáticas y próximos objetivos de refactorización

Answer 17

Y 10 años después ... En 2018 los uso todos Checkstyle, PMD y FindBugs.

Comience con FindBugs . Tal vez agregue PMD y Checkstyle más tarde.

¡Nunca haga cumplir ciegamente las reglas predeterminadas !

Pasos:

• ejecutar una herramienta con reglas predeterminadas en un proyecto que tiene un montón de código
• adaptar las reglas a este proyecto, comentar reglas inútiles con algunas notas
• centrarse en las reglas de frutas que cuelgan bajas (NPE, verificaciones de madereros, verificaciones de recursos no cerradas, ...)
• realiza algunas correcciones para las reglas que encuentres que valen la pena (¡una a la vez!)
• ¡haz esto para cada herramienta, pero no todas a la vez!
• repite este proceso

Idealmente, cada proyecto puede tener reglas separadas. Me gusta ejecutar las reglas a través de la compilación (a través de los complementos de Maven) y fallar en los errores de las reglas una vez que sé que un proyecto aprueba todas las reglas que definí. Esto obliga a los desarrolladores a tomar medidas, porque los informes no son suficientes . A partir de ese momento, su proyecto es prácticamente a prueba de balas e incluso podría agregar más reglas más adelante y / o escribir reglas personalizadas.