Estilo de control frente a PMD

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.

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.

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

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/

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

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

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.

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

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

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.

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.

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.

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

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>

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.

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.

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.

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