http://forge.isotrol.org/

Una de las cosas que mas gracia me hizo fue encontrarme un codigo que usaba un numero raro (digamos 313) tal cual. Le pedi al desarrollador que cambiara ese 313 por una constante, y que la constante tuviera un nombre explicativo. Resultado? el codigo empezo a utilizar la constante THREE_HUNDRED_THIRTEEN

creo que el número de parámetros de las funciones también es una buena métrica: cuando hay que pasar demasiados es probablemente porque una parte de esos parámetros (si no todos) podría pasar a ser una clase (una instancia de una clase) de la que no se es consciente. Por lo general, si uno no se acuerda de cuántos parámetros hay que pasar es que hay demasiados (y se deben agrupar en una clase).

Pero yo no soy IS sino matemático.

Pedro.

Por eso precisamente comento que hay que entender el porqué de la métrica. Si esta desfasada, como lo de final o del único return, debemos saberlo y sabiéndolo, podemos configurar PMD para que no tenga esa métrica en cuenta.

No se debe arreglar el código sin saber el por qué de la métrica, pero tampoco se puede uno emperrar en cumplir TODAS las métricas sin analizar primero si realmente son útiles o no.

Se bueno.

Y más cosas por el estilo, como crear objetos dentro de bucles o la métrica de un único “return”… ya no es sólo cuestión de entender la métrica y hacer un código limpio y eficiente

De todos modos, yo no me obsesionaría con pasar las métricas, pero sí que empujaría a mis equipos a que fueran sistemáticamente mejorándolas. Además de leer dos libros estupendos:
* Implementation Patterns [2] de Kent Beck
* Clean Code [3] de Robert C. Martin

[1] http://code.google.com/p/testability-explorer/
[2] http://www.infoq.com/articles/implementations-patterns-br
[3] http://www.infoq.com/articles/clean-code-book-review

Todavía anda por ahí una de las primeras clases que hice en serio para un proyecto, a la que posteriormente alguien bautizó como “la mega clase”. Una única clase con más de tres mil líneas de código y unos cien métodos. Y eso que de aquella me había hecho mi clase de “modelo de datos”, mis clases de “comunicaciones con el exterior”, mis clases de “interface de usuario/vista” y todo eso que es bueno. Pero la falta de experiencia me hizo hacer la clase principal que junta todo eso como esa gran “mega clase”. No me habría venido mal que alguien me contara algo de métricas entonces.

Gracias por los enlaces, les echaré un ojo.

Se bueno.

En concreto, métricas sobre código fuente, son de los peores indicadores que puedes encontrarte, al menos todo lo relacionado con análisis estático (kloc, complejidad, nº variables/métodos y similares). Es decir, no son incorrectas, pero en muy pocas ocasiones te van a servir para algo realmente útil (definiendo útil algo que te ayuda a tomar decisiones o mejorar en algo).

Si tuviese que elegir alguna métrica sobre el código, elegiría algún indicador relacionado con test unitarios (ejecuciones con éxito, coverage, bug detectados por test, …) o con la historia del mismo (evolución de código nuevo vs modificado, comprobación de partes copypasteadas, incluso respecto a código de otros proyectos).

Si quieres leer del tema, este par de links son realmente buenos y merece la pena echarles un vistazo.