CheckStyle – Tengamos todos el mismo estilo.

Hola Programador@s:

¿Quién sabe qué es el CheckStyle?

Fue por allá en septiembre de 2016 cuando formé parte de un grupo de desarrolladores con mucha mas experiencia que yo en la programación en grupo.

El CTO «impuso» de buen rollo ciertas directrices, entre ellas figuraba el CheckStyle (algo desconocido para mi hasta ese momento).

Se trataba de aplicar en nuestros entornos de desarrollo un sistema que comprobaba que todos las clases que se escribían tenían el mismo estilo para todos los programadores, es una comprobación sintáctica y casi tipográfica.

Además, de esta forma, a cualquier programador del grupo le resultará familiar leer el código de otro compañero.

Ahora en 2018, y con un nuevo proyecto, esta vez en solitario, decido aplicar aquellas buenas prácticas.

Configuración Gradle e IntelliJ

En esta ocasión usando Gradle e IntellliJ estos fueron mis pasos a seguir

Por un lado tuve que añadir a IntelliJ el siguiente plugin que nos permite establecer una configuración mediante un archivo checkstyle.xml que se debe encontrar en:

El plugin que debemos aplicar es http://checkstyle.sourceforge.net/

En este enlace podéis encontrar el manual de instalación para IntelliJ http://checkstyle.sourceforge.net/idea.html

En el momento de activar este plugin, automáticamente, cada vez que abrimos una clase, el IDE nos hace una revisión automática y nos indica cuales son los errores (es decir qué sintaxis no cumplen con nuestra propia configuración)

El tema ahora es que toca hacer que Gradle también nos haga esta comprobación antes de compilar, por si se nos ha escapado algo.

Debemos apligar la siguiente configuración.

Una vez que empecemos a trabajar con nuestro CheckStyle veremos que en determinados momentos nos puede interesar que algunas de las restricciones/comprobaciones no se apliquen.

Para hecho necesitaremos añadir una notación que puede ser a nivel de clase, método o parámetro.

Por ejemplo, en la clase principal, en un aplicación Spring Boot, es necesario que la comprobación HideUtilityClassConstructor no sea aplicada, es decir, que las clases estáticas que por lo general no deberían tener un constructor accesible, en esta única clase sí lo permita, ya que esto va en contra de lo que necesita Spring.

Tendríamos que aplicar la anotación a la clase o al método.

Pero si queremos ser más concretos, sería conveniente limitarlo sólo a HideUtilityClassConstructor y que el resto de comprobaciones sí sean aplicadas. Como es el caso de que los parámetros de los métodos deben ser todos finales.

Configuración CheckStyle

Para hecho necesitamos añadir unos parámetros concretos a nuestro checkstyle.xml

Y esto más abajo

por último a las configuraciónes que queramos poder suprimir hay que darles un id:

Esto nos permitirá colocar anotaciones del siguiente estilo:

Si queremos aplicar varias supresiones se debe indicar de la siguiente manera, como array de cadenas con {} y separado por , :

Nota importante:

En el caso de Spring Boot, no aplicar esta supresión y modificar el método main a private nos provocaría el siguiente error de compilación:

:bootJar FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ‘:bootJar’.
> The value of a manifest attribute must not be null (Key=Start-Class).

Porque el compilador no encuentra la clase principal de la aplicación

Resultado

A continuación os muestro mi checkstyle actual con algunas de las configuraciones suprimibles. Es un checkstyle que circula por la comunidad de desarrolladores con algunos cambios propios.

Espero que os sea de utilidad.

Dejar un comentario