checkstyle findbugs sonarqube pmd

¿Reemplazo de SonarQube para Checkstyle, PMD, FindBugs?



(8)

... unos años después: ¡no, no lo es! SonarQube supone poder cubrir todas las reglas con su propio analizador, pero todavía hay reglas de PMD o CheckStyle no cubiertas por SonarQube. Ver por ejemplo: PMD ReturnFromFinallyBlock.

Estamos trabajando en un proyecto web desde cero y estamos mirando las siguientes herramientas de análisis de código estático.

  • Convenciones (Checkstyle)
  • Malas prácticas (PMD)
  • Errores potenciales (FindBugs)

El proyecto está construido en Maven. En lugar de utilizar múltiples herramientas para este propósito, estaba buscando una única solución flexible y me encontré con SonarQube.

¿Es cierto que podemos lograr los resultados de Checkstyle, PMD y Findbugs con SonarQube?


Bueno, al menos desde SonarQube 6.3+ parece ser que Findbugs (por el momento) ya no es compatible como un complemento. Sonarsource está trabajando en reemplazos de reglas de Findbugs con su propio plugin de Java.

Incluso tienen una lista para el estado de reemplazo de cada regla aquí: http://dist.sonarsource.com/reports/coverage/findbugs.html


Si y no. Además de las otras respuestas.

SonarQube actualmente está en camino de depreciar el PMD, Checkstyle y Findbugs y usar su propia tecnología para analizar el código de Java (llamado SonarJava ). Lo hacen, porque no quieren perder tiempo arreglando, actualizando (o aguardando) esas bibliotecas (p. Ej., Para Java 8) que, por ejemplo, usa bibliotecas desfasadas.

También obtuvieron un nuevo conjunto de complementos para su IDE personal llamado SonarLint .


Sonar ejecutará CheckStyle, FindBugs y PMD, así como algunos otros "complementos" como Cobertura (cobertura de código) de forma predeterminada para proyectos de Java. El principal valor agregado, sin embargo, es que almacena el historial en una base de datos. A continuación, puede ver la tendencia . ¿Estás mejorando la base de código o estás haciendo lo contrario? Solo una herramienta con memoria puede decirte eso.

Debe ejecutar Sonar en su sistema de CI para que se puedan ejecutar incluso las cosas que tarden un poco en ejecutarse (como el CPD - detector de copiar y pegar). Y tendrás tu historia. Mientras que con un plugin de Eclipse, por ejemplo, detectarás violaciones antes, lo cual es genial , pero estarás tentado de ejecutarlo con menos frecuencia si comienza a tomar demasiado tiempo o si ejecutas menos "complementos de calidad" (como omitir CPD o omitiendo el análisis de cobertura de código). Y no tendrás historia.

Además, Sonar genera informes visuales , estilo "Dashboard". Lo que hace que sea muy fácil de entender. Con Sonar en Jenkins, podrá mostrarles a los desarrolladores y a su administración los efectos del trabajo que se realizó sobre la calidad de la base de códigos en las últimas semanas y meses.


Sonar es genial, pero si desea utilizar las herramientas mencionadas por separado y aún tener buenos gráficos, puede usar el Plugin de Analysis Collector como parte de su compilación de Jenkins CI. Una pequeña ventaja de esto es que puede verificar su configuración de PMD / Findbugs / Checkstyle en su SCM y tenerla integrada en su compilación Maven, en lugar de depender de un servidor Sonar por separado.


Sonar es mucho más que solo estas herramientas. Los mayores beneficios es la interfaz gráfica de usuario, que le permite configurar cualquier cosa fácilmente. Las estadísticas que ofrece son muy detalladas (líneas de código, etc.). E incluso ofrece un gran soporte para la cobertura de prueba, etc. :)

Aquí puedes echar un buen vistazo: http://nemo.sonarsource.org/


Sonar utiliza estas 3 herramientas como complementos y agrega los datos de los tres dando valor de suma al mostrar gráficos y otras herramientas de estas. Entonces son complementarios al sonar.


Todavía usaría estas herramientas además del sonar porque pueden fallar en la creación del maven cuando alguien viola una regla. Donde el sonar es más retrospectivo