¿Qué herramientas de análisis de código utiliza para sus proyectos Java? [cerrado]

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

Me interesa 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 IDE y herramientas de compilación.

Si una herramienta solo está disponible de una manera específica (como un complemento IDE o, digamos, un complemento de herramienta de compilación), esa información también es digna de mención.

Para las herramientas de análisis estático , suelo utilizar CPD, PMD , FindBugs y Checkstyle .

CPD es la herramienta "Detector de copiar / pegar" de PMD. Estuve usando PMD por un tiempo antes de que me di cuenta del enlace "Encontrar código duplicado" en la página web de PMD .

Me gustaría señalar que estas herramientas a veces pueden extenderse más allá de su conjunto de reglas "listas para usar". Y no solo porque son de código abierto para que pueda reescribirlos. Algunas de estas herramientas vienen con aplicaciones o "ganchos" que permiten ampliarlas. Por ejemplo, PMD viene con la herramienta de "diseñador" que le permite crear nuevas reglas. Además, Checkstyle tiene el control 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 simple integración en la compilación, encuentro útil configurar las herramientas para que estén algo "integradas" en un par de otras formas. Es decir, uniformidad en la generación de informes y supresión de advertencias. Me gustaría agregar estos aspectos a esta discusión (que probablemente también debería tener la etiqueta "análisis estático"): ¿cómo está configurando la gente estas herramientas para crear una solución "unificada"? (He hecho esta pregunta por separado aquí )

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 de Emacs", pero incluso si no está utilizando 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 cadenas de filtros Ant .

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

Por ejemplo, la configuración predeterminada de PMD suprime la generación de advertencias en líneas de código con la cadena " NOPMD" en un comentario. Además, PMD admite la @SuppressWarningsanotación de Java . Configuro PMD para usar comentarios que contengan " SuppressWarning(PMD." en lugar de NOPMDque las supresiones de PMD se vean iguales. Completo 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 apoyo de PMD a la @SuppressWarninganotación que reconoce las violaciones de las reglas individuales por su nombre:

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

De manera similar, Checkstyle suprime la generación de advertencias entre pares de comentarios (no se proporciona soporte de anotaciones). De forma predeterminada, los comentarios para activar y desactivar Checkstyle contienen las cadenas CHECKSTYLE:OFFy CHECKSTYLE:ON, respectivamente. 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 estilo de verificación, la violación de verificación particular ( HiddenField) es significativa porque cada verificación tiene su propio BEGIN/ENDpar de comentarios.

FindBugs también admite la supresión de la generación de advertencias con una @SuppressWarningsanotación, por lo que no se requiere ninguna configuración adicional para lograr cierto nivel de uniformidad con otras herramientas. Desafortunadamente, Findbugs tiene que admitir una @SuppressWarningsanotación personalizada porque la @SuppressWarningsanotación Java incorporada tiene una SOURCEpolítica de retención que no es lo suficientemente sólida como para retener la anotación en el archivo de clase donde FindBugs la necesita. Califico completamente las supresiones de advertencias de FindBugs para evitar chocar con la @SuppressWarningsanotación de Java :

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

Estas técnicas hacen que las cosas parezcan razonablemente consistentes en todas las herramientas. Tenga en cuenta que hacer que cada supresión de advertencia contenga la cadena " SuppressWarnings" facilita la ejecución de una búsqueda simple para encontrar todas las instancias de todas las herramientas en una base de código completa.

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

EclEmma es un increíble complemento de Eclipse que muestra la cobertura del código coloreando la fuente de Java en el editor ( captura de pantalla ); la cobertura se genera al ejecutar 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 revisar el informe para ver qué clases tienen poca 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 el momento de la compilación. Usamos esto para obtener informes generales del proyecto, que son más útiles cuando desea números agregados. Estos son generados por nuestras compilaciones de CI, que se ejecutan utilizando Continuum .

Todo lo siguiente lo usamos e integramos fácilmente en nuestras compilaciones de Maven 2.xy Eclipse / RAD 7:

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

Además, en nuestras compilaciones de Maven tenemos:

• JDepend
• Comprobador de etiquetas (TODO, FIXME, etc.)

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

Nota: Clover tiene una integración lista para usar con el servidor 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 Hudson CI también los tiene.

Utilizo el análisis estático integrado en IntelliJ IDEA. Perfecta integración.

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

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

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

Estamos utilizando FindBugs y Checkstyle, así como Clover para la cobertura de código.

Creo que es importante tener algún tipo de análisis estático que respalde tu desarrollo. Desafortunadamente, todavía no se ha difundido ampliamente que estas herramientas son importantes.

Usamos FindBugs y JDepend integrados con Ant. Usamos JUnit pero no usamos 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 bien que se ve cuando se ejecuta javac en la consola de Windows. :PAGS

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 como parte de su compilación normal y se puede integrar en Hudson.

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

en nuestro proyecto usamos Sonar delante de checkstyle, pmd .... junto con el CI (Bamboo, Hudson) también obtenemos una buena historia de la calidad de nuestra fuente y la dirección a la que vamos. Me gusta Sonar, porque tienes una herramienta central en CI Stack que lo hace por ti y puedes personalizar fácilmente las reglas para cada proyecto.

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

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 usamos:

• Findbugs para buscar errores comunes de mala / codificación: se ejecuta desde maven y también se integra fácilmente en Eclipse
• Cobertura para nuestros informes de cobertura: ejecutado desde maven

Hudson también tiene un complemento de escáner de tareas que mostrará un recuento de sus TODO y FIXMEs, además de mostrar dónde están en los archivos de origen.

Todos están integrados con Maven 1.x en nuestro caso y conectados a Hudson, que ejecuta nuestras compilaciones en el check-in, así como cosas adicionales cada noche y semanalmente. Hudson muestra gráficas de tendencias de nuestras pruebas JUnit, cobertura, detección de errores y tareas abiertas. También hay un complemento de Hudson que informa y representa gráficamente nuestras advertencias de compilación. También tenemos varias pruebas de rendimiento con sus propios gráficos de rendimiento y uso de memoria a lo largo del tiempo utilizando también el complemento de gráficos de Hudson.