El libro de Kevlin Henney tiene la suerte de contar con contribuciones de grandes expertos, incluyendo a Uncle Bob, por ejemplo. Aunque el libro es de 2010 sigue siendo una de las mejores referencias para las buenas prácticas en el desarrollo de software

Hoy quería centrarme en la número 79 y recordar que las herramientas están ahí para ayudarte, no estas solo y no puedes saberlo todo.

Remontándonos a la época donde el lenguaje C era el nuevo lenguaje de moda, los recursos de cpu y de almacenamiento eran algo de lujo. Los primeros compiladores estaban diseñados con esto en mente, para que se redujese el número de veces que se parseaba el código. Esto hacía que el compilador solo comprobase un subconjunto de todos los bugs posibles que se podían detectar en tiempo de compilación.

Para compensar esta situación, Stephen Johnson escribió una herramienta que se llamaba lint (esto ya si que os sonará de algo, verdad… ¿de dónde pensabáis que venía pylint, jslint, sonarlint, …?). Esta herramienta implementaba parte del análisis estático que había sido eliminada de su hermano mayor -el compilador de C-. Sin embargo, en aquella época, las herramientas de análisis estático se ganaron la reputación de detectar demasiados falsos positivos y de únicamente centrarse en convenciones de nombres que no siempre eran necesarias.

Pero hoy en día el abanico actual de lenguajes, compiladores y analizadores estáticos es muy diferente. La memoria y la CPU no son el factor determinante, por lo que los compiladores deberían poder incluir muchas más comprobaciones. Casi todos los lenguajes disponen de una herramienta que comprueba evidencias de estilo, buenas prácticas y a veces hasta errores que son muy difícil de detectar, como por ejemplo referencias a nulo. La mayoría de herramientas, como splint para C o pylint para Python, son configurables, lo que significa que puedes elegir que errores o advertencias quieres detectar a través de ficheros de configuración, desde la línea de comandos, o en tu entorno de desarrollo favorito.

Y si todo lo demás no es suficiente, y al final te encuentras solo en la búsqueda de errores o tienes una normativa de desarrollo que tu compilador o tu herramienta favorita no controla, pues siempre puedes pensar en construir tu propio analizador estático. No es tan difícil. La mayoría de lenguajes ya exponen su arbol sintáctico (AST) y sus herramientas de compilación como librerías estándar. Puede parecer una locura pero no lo es. Utilizando reglas XPath o kits de desarrollo como SSLR de SonarQube puedes construir tu propio conjunto de buenas prácticas y utilizarlos en diferentes herramientas para ayudarte.

Así que no seas insconciente, benefíciate de todas las ventajas de las herramientas de análisis estático porque no estas solo ahí fuera.