Revisiones de código automatizadas con Eclipse (II): Cómo crear tu propia configuración en CheckStyle

En mi anterior post de Revisiones de código automatizadas con Eclipse aproveché para hacer una mini presentación de varios de los plugins más conocidos de Eclipse para analizar código Java. Posteriormente yo decidí usar el plugin de David Schneider para CheckStyle, principalmente por la facilidad con la que puedes configurar tu propio juego de reglas.

Al final lo que intentas con este tipo de herramientas es asegurarte de que el código de tus proyectos sigue un mismo estilo que asegura un mínimo de calidad y, sobretodo, facilita su mantenimiento. Ahora bien, un estilo es algo subjetivo de por sí y necesita definirse, así que cuanto más facil sea definirlo mejor. Otras ventajas significativas son su facilidad de uso, que los mensajes de las reglas están en castellano y la posibilidad de implementar tus propias reglas.

Instalación
Instalar el citado plugin de CheckStyle en Eclipse es tan sencillo como ir a la opción Help -> Software Updates -> Find and Install. Añadir como Remote Site la url: http://eclipse-cs.sourceforge.net/update/ e ir dándole al botón de siguiente...

Crear una nueva configuración
Una vez instalado puedes configurarlo de forma global en la opción Window -> Preferences -> CheckStyle. Aunque tambien puedes configurar cada proyecto individualmente.


Desde esta pantalla puedes crear tus propias configuraciones o juegos de reglas desde cero o copiando una ya existente. Las configuraciones iniciales (Sun y Sun-Eclipse) no pueden modificarse. Tambien puedes exportar/importar configuraciones e indicar la que se usará por defecto.

Añadiendo reglas
Llegados a este punto selecciona tu nueva configuración y pulsa el botón Configure. En la pantalla de configuración podrás examinar el conjunto de reglas disponible, añadir y parametrizar las reglas de tu elección. Uno de los parametros más importantes es la prioridad. Existen tres niveles de prioridad para las reglas que se comparten con los mensajes del propio Eclipse: error, advertencia e información.


El conjunto de reglas disponible es muy completo y está clasificado en los siguientes grupos:

• Comentarios Javadoc: facilitar el mantenimiento pasa por comentar el código, pero luego los comentarios también hay que mantenerlos... CheckStyle tiene muchas reglas para los javadoc y es muy flexible. Te permite, por ejemplo, obligar a comentar los nombres de clases, todos los métodos menos los get/set y los atributos públicos.
  
• Convenciones de nombres: puedes definir una expresión regular para el nombre de todo. En este punto yo copio las reglas de Sun.
  
• Cabeceras: expresiones regulares para la cabecera de los ficheros.
  
• Imports: reglas para los import, como no usar *, imports sin usar, etc.
  
• Violaciones de tamaño: define un máximo para el tamaño de tus clases, métodos, líneas y número de parametros de un método.
  
• Espacios en blanco: un montón de reglas para definir donde se ponen espacios en blanco y tabuladores en el código.
  
• Modificadores: establece un orden para los modificadores y evita modificadores innecesarios.
  
• Bloques: reglas para los bloques de codigo y sus llaves.
  
• Problemas en la codificación: aquí hay de todo, desde malas prácticas tipo asignaciones internas y posibles fuentes de bugs como definir un método equals que no es el equals(Object), a cosas más estéticas o pijillas, como que el default sea el último elemento en un switch o parentesis innecesarios.
• Diseño de clases: varias reglas sobre el diseño de interfaces y clases, con especial atención en las excepciones.
  
• Duplicados: te permite definir un mínimo de líneas para buscar codigo duplicado en tus clases.
  
• Métricas: define máximos para métricas como complejidad ciclomática, complejidad de expresiones lógicas, npath, líneas de código seguidas sin comentar y dependencia de clases.
  
• Misceláneo: variables final, indentación, un buscador de expresiones regulares y varias cosas más.
  
• J2EE: reglas para EJBs.
• Otros: internos a CheckStyle y activados por defecto.
  
• Filtros: para eventos de auditoria del propio CheckStyle, no hace falta mirarlos.

Cómo usar CheckStyle
La configuración que indiques por defecto se asignará inicialmente a todos tus proyectos, aunque puedes configurar cada proyecto individualmente con una, varias o ninguna configuración.

Además puedes elegir entre tener CheckStyle activado todo el tiempo o usarlo a petición. Todo ello pulsando el botón derecho sobre el proyecto y yendo al menú de CheckStyle. Conforme se incumplan reglas irán saliendo los mensajes correspondientes en la vista Problems de Eclipse ordenados por prioridad y en español!

Pero una vez instalado el plugin, creada la configuración y distribuida entre los miembros del equipo, pasa a ser responsabilidad del programador usar la herramienta y autorevisar su código. Y aquí empieza lo difícil, ¿cuántas reglas y de qué tipo permitirás que no se cumplan en un commit? ¿qué hacer cuando alguién no cumple con las revisiones? ¿cómo detectarlo? ¿todo esto se puede automatizar un poco más?

La única respuesta que tengo cierta es para la última pregunta: sí, con integración continua... pero eso será ya otro post.