Pregunta

¿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 otra)
  • herramientas de cobertura de código (Cobertura, Emma y otras)
  • cualquier otra herramienta basada en instrumentación
  • cualquier otra cosa, si me falta algo

Si corresponde, indique también qué herramientas de compilación utiliza y qué tan bien se integran estas herramientas tanto con sus IDE como con sus 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 mencionar esa información.

¿Fue útil?

Solución

Para herramientas de análisis estático suelo utilizar CPD, PMD, encontrar errores, y Estilo de cuadros.

CPD es la herramienta PMD "Copiar/Pegar Detector".Estuve usando PMD por un tiempo antes de notar el Enlace "Encontrar código duplicado" sobre el página web del 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 sólo porque sean de código abierto para que puedas reescribirlos.Algunas de estas herramientas vienen con aplicaciones o "ganchos" que permiten ampliarlas.Por ejemplo, PMD viene con el herramienta de "diseñador" que te permite crear nuevas reglas.Además, Checkstyle tiene la Token descendiente compruebe que tenga propiedades que permitan una personalización sustancial.

Integro estas herramientas con una construcció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, me resulta útil configurar las herramientas para que estén algo "integradas" de otras maneras.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 configura 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

A esto se le suele llamar "formato 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 Ant cadenas de filtro.

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 una apariencia consistente, lo que parece algo tonto.Cuando suprimes una advertencia, estás suprimiendo una advertencia, entonces, ¿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 Java @SuppressWarnings anotación.Configuro PMD para usar comentarios que contengan "SuppressWarning(PMD." en lugar de NOPMD para que las supresiones de PMD se parezcan.Completo 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 el "SuppressWarnings(PMD."La parte es importante para un comentario, pero es consistente con el apoyo del PMD a la @SuppressWarning anotación que reconoce violaciones de 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 para anotaciones).De forma predeterminada, los comentarios para activar y desactivar 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 comentarios de Checkstyle, la infracción de verificación particular (HiddenField) es significativo porque cada cheque tiene su propio "BEGIN/END"par de comentarios.

FindBugs también admite la supresión de la generación de advertencias con un @SuppressWarnings anotación, por lo que no se requiere configuración adicional para lograr cierto nivel de uniformidad con otras herramientas.Desafortunadamente, Findbugs tiene que soportar una costumbre @SuppressWarnings anotación porque el Java incorporado @SuppressWarnings anotación tiene un SOURCE polí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 conflictos con Java @SuppressWarnings anotación:

@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 cada supresión de advertencia contiene 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.

Otros consejos

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

EclEmma es un impresionante 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 ejecutando una prueba JUnit.Esto es realmente útil cuando intentas determinar qué líneas están cubiertas en una clase en particular, o si quieres 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 revisarlo 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 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 continuo.

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

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

Además, en nuestras compilaciones Maven tenemos:

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

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

Nota:Clover tiene integración inmediata 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 Hudson CI gratuito 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).De nuevo, perfecta integración.

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

Estilo de cuadros es otro que he usado en una empresa anterior...Es principalmente para comprobar el estilo, pero también puede realizar algunos análisis estáticos.También, Trébol para la cobertura del código, aunque tenga en cuenta que no es una herramienta gratuita.

Usamos 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 su desarrollo.Desafortunadamente, todavía no está muy difundido que estas herramientas sean importantes.

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

No lo estoy usando integrado en Rational Application Developer (el IDE que estoy usando para desarrollar aplicaciones J2EE) porque me gusta lo ordenado que se ve cuando ejecuta javac en la consola de Windows.:PAG

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 utiliza PMD y Cobertura, en realidad nuestros proyectos son proyectos maven y es muy sencillo incluir complementos para el análisis de código.La verdadera pregunta sería para un proyecto específico qué análisis necesita usar, mi opinión es que no se pueden usar los mismos complementos para cada proyecto.

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

Estructura 101 es bueno en el análisis de código y en la búsqueda de dependencias de paquetes cíclicos.

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

Mi respuesta a mi propia pregunta es que usamos:

  • Findbugs para buscar errores comunes/codificación incorrecta: se ejecuta desde maven y también se integra fácilmente en Eclipse
  • Cobertura por 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 FIXME, además de mostrar dónde se encuentran en los archivos fuente.

En nuestro caso, todos están integrados con Maven 1.x y vinculados a Hudson, que ejecuta nuestras compilaciones en el check-in, así como cosas adicionales cada noche y semanalmente.La tendencia de Hudson grafica nuestras pruebas JUnit, cobertura, búsqueda de errores y 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 memoria a lo largo del tiempo utilizando el complemento de gráficos Hudson.

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