Guía Completa de Análisis Estático de Código con Detekt y Ktlint

Seguro que te ha pasado: abres un pull request con una funcionalidad que te ha costado sudor y lágrimas, y de repente llega un compañero a decirte que falta una línea en blanco o que un import sobra. Es frustrante, ¿verdad? Esas pequeñas correcciones, aunque sean vitales para que el proyecto no sea un caos, consumen un tiempo precioso y alargan los ciclos de revisión, quitándonos energía para lo que realmente importa: crear funciones que mollen.

Para evitar estas discusiones infinitas sobre dónde poner una llave, han surgido herramientas de análisis estático. Básicamente, se trata de examinar el código fuente sin necesidad de ejecutarlo para pillar bugs potenciales, fallos de estilo o problemas de seguridad antes de que lleguen a producción. En el ecosistema de Kotlin, el combo ganador suele ser Detekt y Ktlint, aunque existen otras alternativas como Diktat que también merecen un vistazo.

Ktlint: El guardián del estilo

Si quieres que tu código parezca escrito por una sola persona, aunque estéis diez programadores, Ktlint es tu mejor aliado. Es un linter muy ligero que se centra en el formateo y la estética, siguiendo las guías oficiales de JetBrains y Android. Lo mejor de todo es que no se anda con rodeos: su filosofía es el «anti-bikeshedding», lo que significa que tiene una configuración mínima para que no pierdas horas debatiendo reglas irrelevantes.

La joya de la corona es la tarea ktlintFormat. En lugar de corregir los errores uno por uno, esta función reescribe automáticamente el árbol de sintaxis (AST) para arreglar espacios, sangrías y comas sobrantes. Para instalarlo, basta con añadir la dependencia en el archivo Gradle del módulo y crear un archivo ktlint.gradle donde se definan las tareas de verificación y formateo. Al ejecutarlo, el sistema te dirá si todo está en orden o si hay fallos que requieren intervención manual.

Detekt: Buscando el «olor» del código

Mientras que Ktlint se encarga de que el código esté «bonito», Detekt va un paso más allá y se mete en el barro de la calidad estructural. Su objetivo es detectar los llamados code smells, que son esos patrones que, aunque no rompan la app, indican que el código se está volviendo difícil de mantener o demasiado complejo.

Detekt analiza conceptos como la complejidad ciclomática, el tamaño excesivo de las clases o el uso de «números mágicos». Para ponerlo en marcha, se añade el plugin de Detekt en el build.gradle.kts y se ejecuta la tarea detektGenerateConfig. Esto genera un archivo detekt.yml donde puedes activar o desactivar reglas según el criterio de tu equipo. Entre sus categorías destacan:

Complejidad: Avisa cuando una función es demasiado larga o tiene demasiados niveles de anidación.
Posibles bugs: Detecta casts inseguros o miembros privados que no se utilizan.
Rendimiento: Identifica la creación redundante de colecciones o concatenaciones de strings ineficientes.
Corrutinas: Evita el uso de scopes globales o modificadores suspend innecesarios.

Comparativa y herramientas alternativas

En el mercado también encontramos a Diktat, una herramienta extremadamente rigurosa basada estrictamente en las convenciones de Kotlin. Sin embargo, muchos equipos la encuentran demasiado agresiva, ya que obliga a documentar absolutamente todo con KDoc, lo que puede generar mucho ruido y archivos de configuración gigantescos para poder desactivar las reglas que no encajan con la realidad del proyecto.

Si comparamos las tres, Ktlint es el más rápido por no usar resolución de tipos, Detekt es el más versátil gracias a su capacidad de análisis profundo y Diktat es el más ortodoxo. A menudo, la mejor estrategia es combinar Detekt y Ktlint, ya que Detekt incluso puede actuar como un envoltorio para las reglas de Ktlint, dándote un informe unificado de calidad y estilo.

Subiendo de nivel: Reglas personalizadas en Detekt

A veces, las reglas estándar no son suficientes porque cada proyecto tiene sus propias manías o convenciones. Detekt permite crear conjuntos de reglas a medida mediante la creación de un proyecto Gradle independiente que implemente la interfaz RuleSetProvider. Esto se hace utilizando el patrón Visitor, donde el analizador recorre el árbol de PSI (Program Structure Interface) del compilador de Kotlin.

Por ejemplo, si quisieras obligar a que los métodos de una clase sigan un orden de visibilidad (públicos primero, luego protegidos, internos y finalmente privados), podrías programar una regla que visite cada KtNamedFunction y compare su modificador de visibilidad con el anterior. Una vez creada la librería y el archivo de servicios en META-INF, solo tienes que añadir el JAR como plugin en tu proyecto principal y activar la nueva regla en el YAML.

Automatización en el flujo de trabajo

De nada sirve tener estas herramientas si el equipo se olvida de ejecutarlas. Para que la calidad sea constante, lo ideal es integrarlas en la canalización de CI/CD (como GitHub Actions, GitLab CI o Jenkins). De este modo, cualquier pull request que no cumpla los estándares será rechazado automáticamente antes de que un humano tenga que revisarlo.

Otra opción muy efectiva es el uso de Git Hooks, específicamente el pre-commit. Al crear un script en .git/hooks/, puedes hacer que el sistema lance ktlintCheck y detekt cada vez que alguien intente hacer un commit. Si hay errores, el commit no se realiza, forzando al desarrollador a limpiar su código en el momento, lo que reduce drásticamente el tiempo de revisión y evita que el repositorio se llene de «commits de limpieza» absurdos.