java - software - sonarqube español

¿Qué herramientas de análisis de código usa para sus proyectos Java? (12)

Estamos usando FindBugs y Checkstyle, así como Clover para Cobertura de código.

Creo que es importante tener algún tipo de análisis estático, apoyando su desarrollo. Desafortunadamente, todavía no está ampliamente difundido que estas herramientas sean importantes.

¿Qué herramientas de análisis de código usa en sus proyectos Java?

Estoy interesado en todo tipo

herramientas de análisis de código estático (FindBugs, PMD y cualquier otro)
herramientas de cobertura de código (Cobertura, Emma y cualquier otra)
cualquier otra herramienta basada en instrumentación
cualquier otra cosa, si me falta algo

Si corresponde, también indique qué herramientas de compilación utiliza y qué tan bien se integran estas herramientas con sus IDEs y herramientas de compilación.

Si una herramienta solo está disponible de una manera específica (como un complemento IDE o, por ejemplo, un complemento de herramienta de compilación), también vale la pena tener en cuenta esa información.

Estoy buscando muchas respuestas para aprender sobre nuevas herramientas y consolidar este conocimiento en una sola pregunta / hilo, por lo que dudo que haya 1 respuesta verdadera a esta pregunta.

Mi respuesta a mi propia pregunta es que utilizamos:

Findbugs para buscar errores comunes mal / codificación - ejecutar desde maven, y también se integra fácilmente en Eclipse
Cobertura para nuestros informes de cobertura: ejecute desde maven

Hudson también tiene un complemento de escáner de tareas que mostrará un recuento de sus TODO y FIXME, y también mostrará dónde se encuentran en los archivos fuente.

Todos están integrados con Maven 1.x en nuestro caso y están vinculados con Hudson, que ejecuta nuestras compilaciones al momento del check-in, así como también cosas adicionales todas las noches y semanalmente. La tendencia Hudson representa gráficamente nuestras pruebas JUnit, cobertura, findbugs, así como las tareas abiertas. También hay un complemento de Hudson que informa y grafica nuestras advertencias de compilación. También tenemos varias pruebas de rendimiento con sus propios gráficos de rendimiento y uso de la memoria a lo largo del tiempo utilizando el plugin Hudson Plots también.

He tenido buena suerte con Cobertura. Es una herramienta de cobertura de código que se puede ejecutar a través de su script ant y como parte de su compilación normal y se puede integrar en Hudson.

Nuestro equipo usa PMD y Cobertura, en realidad nuestros proyectos son maven y es muy simple incluir complementos para el análisis de código. La verdadera pregunta sería para el proyecto específico, qué análisis debe usar, mi opinión es que no podría usar los mismos complementos para cada proyecto.

Para las herramientas de análisis estático a menudo uso CPD, PMD , FindBugs y Checkstyle .

CPD es la herramienta PMD "Copiar / Pegar detector". Estuve usando PMD por un tiempo antes de notar el enlace "Finding Duplicated Code" en la página web de PMD .

Me gustaría señalar que estas herramientas a veces se pueden extender más allá de su conjunto de reglas "listas para usar". Y no solo porque sean de código abierto para que puedas reescribirlos. Algunas de estas herramientas vienen con aplicaciones o "ganchos" que les permiten extenderse. Por ejemplo, PMD viene con la herramienta de "diseñador" que le permite crear nuevas reglas. Además, Checkstyle tiene la marca DescendantToken que tiene propiedades que permiten una personalización sustancial.

Integro estas herramientas con una compilación basada en Ant . Puedes seguir el enlace para ver mi configuración comentada.

Además de la integración simple en la construcción, me parece útil configurar las herramientas para que estén algo "integradas" de otras maneras. A saber, generación de informe y uniformidad de supresión de advertencia. Me gustaría agregar estos aspectos a esta discusión (que probablemente también debería tener la etiqueta "static-analysis"): ¿cómo están las personas configurando estas herramientas para crear una solución "unificada"? (He hecho esta pregunta por separado here )

Primero, para los informes de advertencia, transformo la salida para que cada advertencia tenga el formato simple:

/absolute-path/filename:line-number:column-number: warning(tool-name): message

Esto a menudo se denomina "formato Emacs", pero incluso si no está usando Emacs, es un formato razonable para homogeneizar informes. Por ejemplo:

/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.

Mis transformaciones de formato de advertencia las realiza mi script Ant con las filterchains Ant.

La segunda "integración" que hago es para la supresión de advertencia. De forma predeterminada, cada herramienta admite comentarios o una anotación (o ambas) que puede colocar en su código para silenciar una advertencia que desea ignorar. Pero estas diversas solicitudes de supresión de advertencia no tienen un aspecto consistente que parece algo tonto. Cuando estás suprimiendo una advertencia, estás suprimiendo una advertencia, ¿por qué no siempre escribes " SuppressWarning ?"

Por ejemplo, la configuración predeterminada de PMD suprime la generación de advertencia en líneas de código con la cadena " NOPMD " en un comentario. Además, PMD admite la anotación @SuppressWarnings de Java. Configuro PMD para usar comentarios que contengan " SuppressWarning(PMD. " En lugar de NOPMD para que las supresiones de PMD se parezcan. NOPMD la regla particular que se viola cuando se usa la supresión de estilo de comentario:

// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained

Solo la parte " SuppressWarnings(PMD. ") Es significativa para un comentario, pero es consistente con el soporte de PMD para la anotación @SuppressWarning que sí reconoce las violaciones de reglas individuales por nombre:

@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended

Del mismo modo, Checkstyle suprime la generación de advertencias entre pares de comentarios (no se proporciona compatibilidad con anotaciones). Por defecto, los comentarios para desactivar y activar Checkstyle contienen las cadenas CHECKSTYLE:OFF y CHECKSTYLE:ON , respectivamente. Al cambiar esta configuración (con "SuppressionCommentFilter" de Checkstyle) para usar las cadenas " BEGIN SuppressWarnings(CheckStyle. " Y " END SuppressWarnings(CheckStyle. ") Hace que los controles se parezcan más a PMD:

// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2 // END SuppressWarnings(Checkstyle.HiddenField)

Con los comentarios de Checkstyle, la violación de verificación particular ( HiddenField ) es significativa porque cada comprobación tiene su propio par de comentarios " BEGIN/END ".

FindBugs también admite la supresión de generación de advertencia con una anotación @SuppressWarnings , por lo que no se necesita configuración adicional para lograr un cierto nivel de uniformidad con otras herramientas. Desafortunadamente, Findbugs tiene que admitir una anotación @SuppressWarnings personalizada porque la anotación Java @SuppressWarnings tiene una política de retención SOURCE que no es lo suficientemente fuerte como para conservar la anotación en el archivo de clase donde FindBugs lo necesita. Califico completamente las supresiones de advertencias de FindBugs para evitar chocar con la anotación @SuppressWarnings de Java:

@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")

Estas técnicas hacen que las cosas se vean razonablemente consistentes en todas las herramientas. Tenga en cuenta que al tener cada supresión de advertencia contenga la cadena " SuppressWarnings " hace que sea más fácil ejecutar una búsqueda simple para encontrar todas las instancias para todas las herramientas en una base de códigos completa.

Todo lo siguiente lo usamos e integramos fácilmente tanto en nuestras versiones de Maven 2.x como en Eclipse / RAD 7:

Pruebas - JUnit / TestNG
Análisis de código - FindBugs, PMD
Cobertura del código - Clover

Además, en nuestras construcciones Maven tenemos:

JDepender
Comprobador de etiquetas (TODO, FIXME, etc.)

Además, si está utilizando Maven 2.x, CodeHaus tiene una colección de prácticos complementos Maven en su proyecto Mojo .

Nota: Clover tiene una integración lista para usar con el servidor de Bamboo CI (ya que ambos son productos de Atlassian). También hay complementos de Bamboo para FindBugs, PMD y CheckStyle pero, como se señaló, el servidor gratuito de Hudson CI también tiene estos.

Usamos FindBugs y JDepend integrados con Ant. Usamos JUnit pero no estamos usando ninguna herramienta de cobertura.

No lo estoy usando integrado a Rational Application Developer (el IDE que estoy usando para desarrollar aplicaciones J2EE) porque me gusta lo limpio que parece cuando ejecutas javac en la consola de Windows. :PAG

Uso el análisis estático incorporado en IntelliJ IDEA. Integración perfecta.

Uso la cobertura de código integrada en Intellij IDEA (basada en EMMA). Nuevamente, integración perfecta.

Esta solución integrada es confiable, potente y fácil de usar en comparación con el ensamblaje de herramientas de varios proveedores.

Uso una combinación de Cobertura, Checkstyle, (Ecl) Emma y Findbugs.

EclEmma es un increíble plugin de Eclipse que muestra la cobertura del código coloreando el origen de Java en el editor ( screenshot ): la cobertura se genera ejecutando una prueba JUnit. Esto es realmente útil cuando intenta averiguar qué líneas están cubiertas en una clase en particular, o si desea ver qué líneas están cubiertas por una sola prueba. Esto es mucho más fácil de usar y útil que generar un informe y luego consultar el informe para ver qué clases tienen baja cobertura.

Los complementos Checkstyle y Findbugs Eclipse también son útiles, generan advertencias en el editor a medida que escribe.

Maven2 tiene complementos de informes que funcionan con las herramientas anteriores para generar informes en tiempo de compilación. Usamos esto para obtener informes generales del proyecto, que son más útiles cuando se desean números agregados. Estos son generados por nuestras compilaciones CI, que se ejecutan utilizando Continuum .

en nuestro proyecto utilizamos Sonar frente a checkstyle, pmd .... junto con el CI (Bamboo, Hudson) obtenemos también una buena historia de nuestra calidad de fuente y qué dirección vamos. Sí me gusta Sonar, porque usted tiene una herramienta central en la Pila CI que lo hace por usted, y puede personalizar fácilmente las reglas para cada proyecto.

Checkstyle es otro que he usado en una empresa anterior ... es principalmente para la comprobación de estilo, pero también puede hacer un análisis estático. Además, Clover para la cobertura del código, aunque tenga en cuenta que no es una herramienta gratuita.

La Estructura 101 es buena para el análisis de código y para encontrar las dependencias del paquete cíclico.