Herramientas de análisis de complejidad de código más allá de la complejidad ciclomática

Question

Si bien la complejidad ciclomática es una métrica que vale la pena, tiendo a encontrar que es una herramienta deficiente para identificar código difícil de mantener. En particular, tiendo a encontrar que solo destaca ciertos tipos de código (por ejemplo, analizadores sintácticos) y omite problemas de recursión, enhebrado y acoplamiento difíciles, así como muchos de los antipatrones que se han definido.

¿Qué otras herramientas hay disponibles para identificar el código problemático de Java?

Nota, ya usamos PMD y FindBugs que creo que son excelentes para la identificación de problemas de nivel de método.

Answer 1

Mi experiencia es que las métricas más importantes cuando se mira en capacidad de mantenimiento de código son:

• Ciclomática Complejidad, para identificar grandes trozos de código que probablemente son difíciles de entender/modificar.
• Profundidad de anidamiento, para encontrar puntos similares (una profundidad de anidamiento alta es CC automáticamente alta, pero no necesariamente al revés, por lo que es importante tener en cuenta la puntuación en ambos).
• Fan in/out, para obtener una mejor visión de las relaciones entre métodos/clases y la importancia real de los métodos individuales.

Al examinar el código escrito por otros, a menudo es útil incluir técnicas dinámicas.Sólo tiene que ejecutar escenarios de uso común mediante una herramienta de cobertura/código de perfiles para descubrir:

• código que se ejecuta realmente mucho (el perfilador es ideal para esto, simplemente ignorar la información de temporización y mirar los recuentos de golpe en su lugar).
• La cobertura de código es excelente para encontrar (casi) código muerto. Para evitar que invierta tiempo en el código de refactorización que rara vez se ejecuta de todos modos.

Los sospechosos habituales, como cualquier herramienta de perfil, cobertura de código y métricas, generalmente le ayudarán a obtener los datos necesarios para realizar estas evaluaciones.

Answer 2

Las herramientas de análisis estático que ya usa son bastante estándar. Si está utilizando Eclipse, intente buscar here para obtener más herramientas de análisis de código.

Emma proporciona un análisis de cobertura de código, aunque esto es realmente para probar.

Answer 3

Google Testability Explorer comprueba, por ejemplo, para singletons y otras cosas estáticas que son malos olores en el diseño. Metrics es un plugin de Eclipse que mide casi todas las métricas de código conocidas por la humanidad. Usé y puedo recomendar ambos fácilmente.

Answer 4

nunca he usado, pero me pareció bastante interesante y prometedor:

http://erik.doernenburg.com/2008/11/how-toxic-is-your-code/

y utilicé éste y lo encontraron muy útil, ya que la buena visualización de las dependencias

http://www.headwaysoftware.com/products/structure101/index.php

Answer 5

Sonar trata de identificar los "puntos calientes" de complejidad y mantenibilidad que combinan los resultados de varias herramientas de código abierto (incluyendo PMD y Findbugs). Se integra bien con los servidores Maven y CI (especialmente Hudson).

EDITAR por extraneon

Hay un sitio Sonar available, donde se analizan una gran cantidad de proyectos de código abierto. Creo que esto muestra bastante bien la cantidad de reglas que se aplican, y hasta dónde va el desglose. Por supuesto, también puede desactivar las reglas que no le parezcan interesantes.

Here es una explicación de las métricas.

Answer 6

La herramienta NDepend de código .NET le permitirá analizar muchas dimensiones de la complejidad del código incluyendo métricas de código como: Ciclomática complejidad, profundidad de anidamiento, la falta de cohesión de los métodos, la cobertura mediante pruebas ...

. ..incluyendo análisis de dependencias e incluyendo Code Rules over LINQ Queries (CQLinq) dedicado a preguntar, qué es complejo en mi código, y escribir regla. Alrededor de 200 default Code Rules se proporcionan. Se refieren anti-patrones como el Singleton, la detección de threading problems, la detección de problemas de acoplamiento como UI layer shouldn't use directly DB types ...

Hace un tiempo, escribí un artículo para resumir varias dimensiones de la complejidad del código: Fighting Fabricated Complexity