Llevo utilizando herramientas de auditoria de código desde hace más de diez años. Concretamente el PMD y Checkstyle y durante un periodo de tiempo muy corto, el Together. Siempre he estado muy interesado en estos temas de hacer las cosas no solo que funcionen sino además procurar hacerlas bien.
En estos más de diez años he ido pasando por una serie de estadios con respecto a la auditoria de código. Inicialmente me parecía muy importante y ponía a mis proyectos una configuración con muchas reglas. Eran épocas en las que estos temas de cuidar la calidad no estaban muy en boga que digamos, así que era una especie de bicho raro.
Con esas configuraciones tan exigentes aprendes una cosa, que si te pasas poniendo reglas no eres capaz de pasar del hola mundo. Y no siempre acaba compensando la mejora de la calidad con el incremento de coste.
Así que empiezas a aligerar las reglas, haciendo una selección más racional.
Poco a poco afortunadamente estas herramientas se han ido popularizando y cada vez más clientes para los que he trabajando lo han ido exigiendo.
Pero cuando extiendes estas herramientas a todo el proyecto te empiezas a dar cuenta de la dificultad y del lado oscuro de las mismas.
El que no tiene criterio para hacerlo bien, no lo hará por mucha herramienta que le pongas. He visto a programadores arreglar errores dejándolo objetivamente peor, pero eso si había desaparecido la alerta.
Esto ocurre por un motivo, estas herramientas no solo detectan errores, sino que detectan patrones sospechosos, por eso hay que tener cierto criterio.
Hay que dejar las cosas sencillas. Algunas empresas para las que he trabajado tienen definidas reglas de auditoria de código en las que el pasar o no el criterio no solo depende del nivel de error sino de cuantas alertas tengas. Es decir por ejemplo el tener un número determinado de alertas de nivel Info puede hacer que no pases el criterio.
Este planteamiento es entendible, en el sentido de que una cosa que igual no está mal, pero se repite mucho puede ser una fuente de problemas. Por ejemplo si usas mucho las conexiones a base de datos, puede ser que cierres todas correctamente, pero es un punto de riesgo.
Este planteamiento puede resultar un poco complicado de hacer cumplir a un equipo de trabajo, porque no saben si lo tienen que cambiar o no.
Yo suelo preferir, siempre y cuando el cliente no tenga sus propias reglas, obviamente, planteamientos más sencillos. Los errores son eso errores y hay que arreglarlos si o si, y el resto de cosas, warnings, info, etc es opcional el arreglarlos.
Una de las cosas que si suelo incorporar a las reglas de auditoria son todas aquellas reglas que aunque no son importantes si son automatizables por los entornos de desarrollo. Por ejemplo el hacer que los if lleven siempre llaves.