Kotlin en equipo: code style y convenciones sobre las que todos discuten

Kotlin en equipo: cómo dejar de discutir sobre el formateo y empezar a escribir código

¿Alguna vez ha hecho una code review donde la mitad de los comentarios se reducían a "pon un espacio", "quita un espacio" o "¿por qué usas CamelCase y no snake_case"? Si es así — bienvenido al club. En cualquier equipo, tarde o temprano surge la pregunta: code style y convenciones de Kotlin. Y si no se acuerda de antemano, cada uno impondrá su "ideal" colocación de llaves.

Este artículo no es una lista seca de reglas. Es una guía práctica para hacer que el código en Kotlin sea legible, uniforme y conveniente para todo el equipo. Analizaremos las convenciones clave, las herramientas de automatización y los trucos que le ahorrarán horas de discusión en las reuniones.

Por qué el code style en Kotlin no es cuestión de estética, sino de dinero

Seamos honestos: al negocio le da igual si pone la llave de apertura en la misma línea o en una nueva. Pero al negocio sí le importa cuánto tiempo se tarda en integrar a un nuevo desarrollador en el proyecto. Los estudios muestran que los desarrolladores dedican hasta el 40% del tiempo a leer código. Si el código está escrito con un code style Kotlin unificado, este proceso se acelera enormemente.

Cuando en un proyecto se utiliza un estilo de código Kotlin unificado:

\n
• Los nuevos miembros del equipo entienden más rápido la estructura del proyecto.
\n
• La code review es más rápida: los revisores buscan errores de lógica, no espacios.
\n
• Se reduce la cantidad de errores debidos a un formateo incorrecto (sí, eso también pasa).
\n
• Los diffs de Git son más limpios: menos ruido por reformateo.
\n

Por lo tanto, las convenciones de Kotlin no son un capricho del líder, sino una herramienta para aumentar la eficiencia. Y ahora veremos cómo implementarlas sin dolor.

Guía oficial: Kotlin Coding Conventions

Empecemos por lo básico: JetBrains tiene un documento oficial: Kotlin coding conventions. No es una ley, pero la gente sabia lo recomienda como punto de partida. Repasemos los puntos clave que suelen generar más controversia.

Nomenclatura: CamelCase para siempre

Kotlin usa CamelCase para todo: clases con mayúscula inicial (MyAwesomeClass), funciones y variables con minúscula inicial (myAwesomeFunction). Las constantes de nivel superior o dentro de un objeto usan SCREAMING_SNAKE_CASE. Nada de guiones bajos en nombres de variables — esto no es Python.

// Correcto\nclass UserProfile\nval userName: String\nfun getUserData(): UserData\n\n// Incorrecto\nclass user_profile\nval user_name: String\nfun get_user_data(): UserData

Llaves: abrir en la misma línea

Kotlin sigue la tradición de Java: la llave de apertura va en la misma línea que la declaración. Esto no se discute, a menos que quiera ser considerado un hereje.

// Kotlin way\nfun processData(data: List<String>) {\n    data.forEach { item ->\n        println(item)\n    }\n}\n\n// No-Kotlin way (pero si todo el equipo escribe así, está bien)\nfun processData(data: List<String>)\n{\n    data.forEach { item ->\n        println(item)\n    }\n}

Espacios: no los escatime

Ponga espacios después de las palabras clave (if, for, when), alrededor de los operadores binarios y después de las comas. Esto mejora la legibilidad.

// Legible\nif (x > 0 && y < 10) {\n    println("Hello, World!")\n}\n\n// Difícil de leer\nif(x>0&&y<10){\n    println("Hello, World!")\n}

Autoformateo: su mejor amigo

La verificación manual del code style es cosa del pasado. Kotlin tiene un formateador integrado en IntelliJ IDEA: Ctrl+Alt+L (o Cmd+Option+L en Mac). Pero si en su equipo alguien usa VS Code u otro editor, los problemas son inevitables.

Solución: ktlint y Spotless.

ktlint: el soldado universal

ktlint es una herramienta que verifica y automáticamente