Estilo de control frente a PMD

86

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

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

También estamos planeando utilizar FindBugs. ¿Existen otras herramientas de análisis estático que deberíamos considerar?

Actualización: el consenso parece ser que se prefiere PMD sobre 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 a PMD. También traeremos FindBugs y quizás, eventualmente, Macker para hacer cumplir las reglas arquitectónicas.

John Stauffer
fuente

Respuestas:

71

Definitivamente deberías usar FindBugs . En mi experiencia, la tasa de falsos positivos es muy baja, e incluso vale la pena abordar hasta cierto punto las advertencias menos críticas que informa.

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

Chris chaleco
fuente
49
+1 por agregar su recomendación de FindBugs. Sin embargo, no estoy de acuerdo con tu opinión sobre Checkstyle a menos que seas un desarrollador solitario con tu propio estilo idiosincrásico. Para los equipos, acordar un subconjunto razonable común de reglas y luego usar una herramienta automatizada como Checkstyle para hacerlas cumplir automáticamente da como resultado un código que todos pueden leer.
John Tobler
1
Si bien no es perfecto, FindBugs es el mejor con diferencia. El PMD y el estilo de control le apuntan hacia malas prácticas. Debe evitarse a toda costa a menos que sepa muy bien qué advertencias son válidas y cuáles no.
DPM
Por extraño que parezca, he tenido exactamente la experiencia opuesta con PMD vs Checkstyle. PMD a menudo informa falsos positivos si es algo que Checkstyle o Findbugs no encontró. Sin embargo, 7 años pueden importar mucho.
xenoterracide
38

Ambos softwares son útiles. Checkstyle le ayudará durante su programación comprobando su estilo de codificación, es decir, llaves, 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 verificará su estilo de programación

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

RUMANIA_engineer
fuente
10
Exactamente. En mi humilde opinión, son 2 herramientas que tienen como objetivo hacer cosas diferentes, así que no estoy seguro de si son comparables. Si desea aplicar un estilo de codificación estándar entre un equipo de desarrollo, use Checkstyle. Si desea analizar el código en busca de problemas de diseño o malas prácticas de codificación, use PMD.
aberrant80
24

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

Estas herramientas no compiten, sino que 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 en comprender códigos inconsistentes.

Ejemplos de estilo de verificación:

  • ¿Existe javadoc en los métodos públicos?
  • ¿El proyecto sigue las convenciones de nomenclatura de Sun?
  • ¿El código está escrito con un formato coherente?

mientras que PMD te recuerda las malas prácticas:

  • Detectar una excepción sin hacer nada
  • Tener código muerto
  • Demasiados métodos complejos
  • Uso directo de implementaciones en lugar de interfaces
  • Implementar el método hashcode () sin el método not equals (objeto objeto)

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

Lucas
fuente
1
Estoy de acuerdo en que Checkstyle, se enfoca más en el formato de código y obliga al desarrollador a seguir el "Código estándar", pero también podría detectar muchas malas prácticas, eche un vistazo aquí , y la extensión de Checkstyle es más fácil de desarrollar, pero estoy de acuerdo que tiene limitaciones y nunca superará a PMD y FindBug.
Roman Ivanov
15

Usamos ambos:

  • Verifique el estilo para asegurarse de que todos en el equipo escriban el código de manera similar
  • PMD para encontrar áreas de código problemáticas y próximos objetivos de refactorización
Ilya Kochetov
fuente
7

Si su lugar principal de uso es durante el desarrollo en eclipse, entonces CodePro de Instantiations será el mejor. Anteriormente era una herramienta comercial, pero ahora Google compró instancias, por lo que CodePro analytix es gratis ahora.

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

Naveen
fuente
7

Si revisó las listas de reglas de Checkstyle, PMD y Findbugs, habrá visto que las tres proporcionan resultados valiosos y las tres se superponen hasta cierto punto y también aportan sus propias reglas únicas a la mesa. Por eso, herramientas como Sonar utilizan los tres.

Dicho esto, Findbugs tiene las reglas más específicas o de nicho (por ejemplo, "Detección dudosa de IllegalMonitorStateException" - ¿con qué frecuencia es probable que se encuentre con eso?), Por lo que se puede usar 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 que el equipo sufra una avalancha de comentarios irrelevantes ("Tab char en la línea 5", "Tab char en la línea 6", "Tab char en la línea 7" ... se obtiene la imagen). También proporcionan herramientas poderosas para escribir sus propias reglas avanzadas, por ejemplo, Checkstyle DescendentToken regla .

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

En resumen, si considera que el análisis de código estático es valioso, rechazar el valor que ofrece cualquiera de los tres no tiene sentido, pero para usar los tres, debe invertir tiempo en configurarlos para brindarle comentarios útiles.

Tomislav Nakic-Alfirevic
fuente
6

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 ...

DaveFar
fuente
5

Ambas herramientas son configurables y pueden hacer casi lo mismo. Dicho esto, si hablamos de cosas listas para usar, hay una gran superposición, 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 forma inmediata y que PMD no hace, podría considerar una configuración mínima de Checkstyle con solo esos controles. Luego, establezca una política que la configuración de Checkstyle no pueda hacer crecer, simplemente elimine los controles a medida que implementa una funcionalidad similar con, digamos, reglas personalizadas de PMD.

También considere que si decide que la función de "control de importación" de Checkstyle cubre lo que desea 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 PMD no hace de inmediato "gratis".

Greg Mattes
fuente
5

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

Otra ventaja de usar PMD es CPD (Copy / Paste Detector). Detecta la duplicación de código en los proyectos y no está restringido a JAVA. También funciona para JSP. Neal Ford tiene una buena presentación sobre desarrollo ágil impulsado por métricas , que habla sobre muchas herramientas que son útiles para el desarrollo Java / Java EE.

Arjan Tijms
fuente
4
Para cualquiera que lea esto ... checkstyle ahora tiene estos checkstyle.sourceforge.net/config_metrics.html checkstyle.sourceforge.net/config_duplicates.html
smp7d
4

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

Lo que recomiendo encarecidamente y con entusiasmo es usar FindBugs. Debido a que funciona a nivel de código de bytes, puede verificar cosas que son imposibles en el nivel de fuente. Si bien escupe una buena cantidad de basura, ha encontrado muchos errores reales e importantes en nuestro código.

Alex Miller
fuente
4

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

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

¡Nunca aplique ciegamente las reglas predeterminadas !

Pasos:

  • ejecutar una herramienta con reglas predeterminadas en un proyecto que tiene mucho código
  • adaptar las reglas a este proyecto, comentar reglas inútiles con algunas notas
  • centrarse en las reglas de las frutas que están al alcance de la mano (NPE, controles de registradores, controles de recursos no cerrados, ...)
  • realice algunas correcciones para las reglas que considere útiles (¡una a la vez!)
  • ¡Haga esto para cada herramienta, pero no para 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 complementos de Maven) y fallar en los errores de reglas una vez que sé que un proyecto pasa 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.

Christophe Roussy
fuente
FYI, SpotBugs es el "sucesor espiritual de FindBugs" , y la documentación de SpotBugs es bastante buena. Hasta donde yo sé, FindBugs no se ha actualizado durante años.
skomisa
Nunca he oído hablar de SpotBugs, probablemente porque FindBugs + fbcontrib fue suficiente durante mucho tiempo, es bueno saber que hay algún reemplazo
Christophe Roussy
Hay una discusión al respecto aquí: news.ycombinator.com/item?id=12885549
Christophe Roussy
También vale la pena señalar que las herramientas tienden a tener sensibilidad configurable. Por ejemplo, al comenzar con FindBugs / SpotBugs, es posible que deba elegir un umbral alto para detectar solo los errores más graves y luego reducir el umbral a medida que soluciona las cosas.
ThrawnCA
@ThrawnCA sí, pero incluso con sensibilidad: en un proyecto grande, se encontrarán demasiados errores que se solucionarán en un período de tiempo razonable. Entonces, lo que hago en su lugar es agregar una regla a la vez, comenzando con las frutas más bajas, como la detección potencial de NP, luego pasar a reglas como los recursos no cerrados.
Christophe Roussy
3

Un punto que no he visto hasta ahora es que hay complementos para IDE que harán cumplir los conjuntos de reglas CheckStyle en su código, mientras que los complementos de PMD solo informarán sobre violaciones. Por ejemplo, en un proyecto de varios sitios sobre varios equipos de programación, es importante hacer cumplir activamente los estándares, en lugar de solo informar sobre ellos.

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, por lo que solo puedo comentar sobre IntelliJ y Eclipse.

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

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

"Bajo demanda" para PMD significa que el desarrollador debe decidir conscientemente ejecutar el informe. Mientras que las infracciones de Checkstyle se les informa automáticamente a medida que se desarrollan. Mientras PMD lo hace contener un conjunto de reglas más extensa, en mi mente la enforecement automática / notificación de violaciónes en entornos de desarrollo es la pena la molestia de mantener 2 conjuntos de reglas.

Entonces, para cualquier proyecto en el que trabajo, utilizamos ambas herramientas, Checkstyle aplicado en el IDE, PMD informado en el IDE, y ambos informados y medidos en compilaciones (a través de Jenkins).

GKelly
fuente
1
También hay formas de integrarlo en la compilación y hacer que falle en caso de violación (con maven, por ejemplo). He hecho esto para Checkstyle, PMD y FindBugs. Como dijiste, informar no es suficiente.
Christophe Roussy
3

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 es necesario 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>
yegor256
fuente
¿Cómo lo configuro para obtener un informe (en algún formato utilizable)? Ahora solo lo escupe en la consola incluso si configuro log4j. Veo que hay un informe de error que podría estar relacionado, pero no estoy seguro.
Adam Arold
Estamos pensando lo mismo pero para solucionarlo necesito que esté resaltado en mi código o algo similar. Al menos tu settings.jarayudaste.
Adam Arold
2

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

Steve Moyer
fuente
1

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

anjanb
fuente
2
Cierto en 2008, pero hoy Checkstyle ha ganado mucha velocidad.
Barfuin
1

Acabo de empezar a utilizar 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, lo cual tampoco es difícil en absoluto. Sin embargo, PMD no me ha demostrado que tenga la función de mostrar el número de columna. Entonces, para cosas como verificar los límites de las columnas. Es posible que desee utilizar Checkstyle.

JP
fuente
-2

PMD es la mejor herramienta en comparación con los estilos de verificación. ¡Es posible que los estilos de verificación no tengan la capacidad de analizar el código mientras que PMD ofrece muchas funciones para hacerlo! Por supuesto, PMD no ha publicado reglas para javadoc, comentarios, sangrías, etc. Y, por cierto, estoy planeando implementar estas reglas ... gracias

Janasainik
fuente
Una cosa buena sobre el estilo de verificación es que permite algunas reglas flexibles como RegexpSingleline ...
Jigar Shah