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

Question

¿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?

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 otro)
cualquier otra herramienta basada en instrumentación
cualquier otra cosa, si me estoy perdiendo 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), esa información también vale la pena señalar.

108

java static-analysis code-coverage

Author: Bill the Lizard, 2008-08-07

Source

12 answers

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

EclEmma es un complemento de Eclipse awesomeque muestra la cobertura del código coloreando el código fuente java en el editor ( captura de pantalla) - la cobertura se genera ejecutando una prueba JUnit. Esto es realmente útil cuando está tratando de averiguar qué líneas están cubiertas en una clase en particular, o si desea ver solo 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 mirar a través del 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 plugins de informes que funcionan con las herramientas anteriores para generar informes en el momento de la compilación. Utilizamos 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 .

16

Author: Ken Liu,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-29 18:55:44

Todos los siguientes utilizamos e integramos easiy en nuestro Maven 2.x construye y Eclipse / RAD 7:

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

Además, en nuestras construcciones Maven tenemos:

JDepend
Tag checker (TODO, FIXME, etc)

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

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

11

Author: Brian Laframboise,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-08-16 18:48:43

Utilizo el análisis estático integrado en IntelliJ IDEA. Integración perfecta.

Utilizo la cobertura de código integrada en Intellij IDEA (basada en EMMA). Una vez más, la integración perfecta.

Esta solución integrada es fiable, potente y fácil de usar en comparación con la combinación de herramientas de varios proveedores.

8

Author: Steve McLeod,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-17 14:40:53

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

4

Author: Mike Stone,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-08-07 07:18:26

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, apoyando su desarrollo. Desafortunadamente, todavía no se ha difundido ampliamente que estas herramientas sean importantes.

3

Author: dlinsin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-08-07 07:21:49

Utilizamos 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 se ve cuando se ejecuta javac en la consola de Windows. : P

1

Author: ggasp,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-08-07 00:20:41

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.

1

Author: Randyaa,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-17 04:31:07

Nuestro equipo utiliza PMD y Cobertura, en realidad nuestros proyectos son proyectos maven y es muy sencillo incluir plug-ins para el análisis de código. La pregunta real sería para el proyecto específico que el análisis que necesita utilizar, mi opinión es que es usted no podría utilizar los mismos plugins para cada proyecto.

1

Author: vaske,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-17 14:46:25

En nuestro proyecto usamos Sonar delante de checkstyle, pmd.... junto con el CI (Bamboo, Hudson) también obtenemos una buena historia de nuestra calidad de origen y qué dirección vamos. Me gusta Sonar, porque es una herramienta central en la pila de CI que lo hace por usted, y puede personalizar fácilmente las reglas para cada proyecto.

1

Author: OneCent,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-08-29 09:56:05

Structure 101 es bueno en el análisis de código y en encontrar las dependencias cíclicas de los paquetes.

1

Author: Jeffrey Lee,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-09-17 06:59:00

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 mal / codificación-ejecutar desde maven, y también se integra fácilmente en Eclipse
Cobertura para nuestros informes de cobertura-ejecutar desde maven

Hudson también tiene un plugin de escáner de tareas que mostrará un recuento de su TAREA y FIXMEs, así como mostrar dónde están en los archivos de origen.

Todos están integrados con Maven 1.x en nuestro caso y atado a Hudson, que ejecuta nuestras construcciones en el check-in, así como las cosas adicionales por la noche y la semana. Hudson trend grafica nuestras pruebas JUnit, cobertura, findbugs, así como tareas abiertas. También hay un plugin 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 memoria a lo largo del tiempo utilizando el Hudson parcelas plugin también.

0

Author: Joshua McKinnon,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-08-08 14:53:12

score 66 · Accepted Answer

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

CPD es la herramienta PMD "Detector de Copiar/Pegar". Estuve usando PMD por un tiempo antes de notar el enlace "Encontrar código duplicado" en la página web 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 son de código abierto que puedes reescribirlos. Algunas de estas herramientas vienen con aplicaciones o "ganchos" que permiten extenderlas. Por ejemplo, PMD viene con la herramienta "designer" que le permite crear nuevas reglas. Además, Checkstyle tiene la comprobación 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 comentario configuración.

Además de la simple integración en la compilación, me resulta útil configurar las herramientas para que estén algo "integradas" en un par de otras maneras. Es decir, generación de informes y uniformidad de supresión de advertencias. Me gustaría añadir estos aspectos a esta discusión (que probablemente debería tener la etiqueta "análisis estático" también): ¿cómo está la gente configurando 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 llama el "formato Emacs", pero incluso si no está utilizando Emacs, es un formato razonable para homogeneizar los informes. Por ejemplo:

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

Mis transformaciones de formato de advertencia se realizan mediante mi script Ant con Ant filterchains.

La segunda "integración" que do 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, 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 soporta la anotación @SuppressWarnings de Java. Configuro PMD para usar comentarios que contengan " SuppressWarning(PMD." en lugar de NOPMD para que las supresiones PMD se parezcan. Relleno la regla particular que se viola al usar 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 para la anotación @SuppressWarning que reconoce violaciones individuales de reglas 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 soporte para anotaciones). Por defecto, los comentarios para desactivar y activar Checkstyle contienen las cadenas CHECKSTYLE:OFF y 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 Checkstyle, la comprobación particular violación (HiddenField) es significativo porque cada cheque tiene su propio par de comentarios "BEGIN/END".

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

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

Estas técnicas hacen que las cosas parezcan razonablemente consistentes entre las herramientas. Tenga en cuenta que tener cada supresión de advertencia contiene la cadena "SuppressWarnings" hace que sea fácil ejecutar una búsqueda simple para encontrar todas las instancias de todas las herramientas sobre una base de código completa.