Pregunta

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

¿Hay algún beneficio en 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 usar FindBugs. ¿Hay otras herramientas de análisis estático que deberíamos mirar?

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 a PMD exclusivamente. También traeremos FindBugs, y quizás, eventualmente, Macker para hacer cumplir las reglas arquitectónicas.

¿Fue útil?

Solución

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

En cuanto a Checkstyle vs. PMD, no usaría Checkstyle ya que solo se refiere al 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 salida es generalmente más relevante y útil.

Otros consejos

Ambos softwares son útiles. Checkstyle lo ayudará durante su programación al verificar su estilo de codificación es decir, llaves, nombres, etc. ¡Cosas simples pero muy numerosas!

PMD lo ayudará comprobando 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 configuración incorrecta, puede verificar las cosas dos 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 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 en comprender códigos inconsistentes.

Ejemplos de estilo de comprobación:

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

mientras que PMD le recuerda malas prácticas:

  • Capturar 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 de objeto)

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

Usamos ambos:

  • Compruebe 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 de uso principal es mientras se desarrolla 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 Checkstyle, PMD y Findbugs, verá que las tres proporcionan resultados valiosos y las tres se superponen en cierto grado y también aportan sus propias reglas únicas a la tabla. Es por eso que herramientas como Sonar usan los tres.

Dicho esto, Findbugs tiene las reglas más específicas o específicas (p. ej., "Captura dudosa de IllegalMonitorStateException", ¿con qué frecuencia es probable que se encuentre con eso?), por lo que es utilizable con poca o ninguna configuración y sus advertencias deben tomarse seriamente. Con Checkstyle y PMD, las reglas son más generales y 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 " ... obtienes la imagen). También proporcionan herramientas poderosas para escribir sus propias reglas avanzadas, p. la regla Checkstyle DescendentToken .

Al usar los tres (especialmente con una herramienta como Sonar), todos 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 ese código hash ( ) ha sido anulado y equals () 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 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 ...

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

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

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

Lo que recomendaría con entusiasmo y entusiasmo es utilizar FindBugs. Debido a que funciona en el nivel de bytecode, puede verificar cosas que son imposibles en el nivel de origen. Si bien escupe una buena cantidad de basura, ha encontrado muchos errores reales e importantes en nuestro código.

Ambas herramientas son configurables y pueden hacer casi las mismas cosas. Dicho esto, si estamos hablando 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 fuerte para verificar Javadoc y encontrar números mágicos, por nombrar un par. Además, Checkstyle tiene un "control de importación" característica que se parece a la funcionalidad de Macker (no he usado Macker).

Si hay cosas que son importantes para usted que Checkstyle hace de manera inmediata que PMD no hace, puede considerar una configuración mínima de Checkstyle con solo esas verificaciones. Luego instituya una política que la configuración de Checkstyle no pueda crecer, simplemente elimine los controles a medida que implementa una funcionalidad similar con, por ejemplo, reglas PMD personalizadas.

También tenga en cuenta que si decide que Checkstyle " import control " La función cubre lo que quería de Macker, luego podría implementar PMD / Checkstyle en lugar de PMD / Macker. De cualquier manera, son dos herramientas, pero con Checkstyle, obtendrás las cosas que PMD no hace de forma inmediata "gratis".

Un punto que no he visto hasta ahora es que hay complementos para IDE que impondrán los conjuntos de reglas CheckStyle en su código, mientras que los complementos PMD solo informarán sobre violaciones. Por ejemplo, en un proyecto de múltiples 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ía del uso). No estoy tan familiarizado con NetBeans, por lo que solo puedo comentar sobre IntelliJ y Eclipse.

De todos modos, los complementos PMD para IntelliJ y Eclipse generarán informes a pedido 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') CR-LF entre declaraciones, para 'NeedBraces', agregará llaves donde faltan, 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 informan automáticamente a medida que se desarrollan. Si bien PMD sí contiene un conjunto de reglas más extenso, en mi opinión, vale la pena la molestia de mantener 2 conjuntos de reglas en la ejecución / notificación automática de violaciones en IDE.

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

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

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

¡Nunca aplique a ciegas las reglas predeterminadas !

Pasos:

  • ejecuta una herramienta con reglas predeterminadas en un proyecto que tiene mucho código
  • adapte las reglas a este proyecto, comente las reglas inútiles con algunas notas
  • centrarse en las reglas de frutas bajas (NPE, comprobaciones de registradores, comprobaciones de recursos no cerradas, ...)
  • realice algunas correcciones para las reglas que considere valiosas (¡una a la vez!)
  • ¡haga esto para cada herramienta pero no todas a la vez!
  • repita 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.

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>

Me gustaría repetir el comentario de que 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 utilizando Coverity.

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

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

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top