Code Review en Kotlin: 7 trampas que matan tu proyecto

¿Por qué el code review en Kotlin no es sobre "yo lo habría escrito diferente"?

El code review (o revisión de código) es un ritual sagrado en cualquier equipo que se respete. Pero cuando se trata de Kotlin, muchos desarrolladores se quedan perplejos. "¡Aquí todo es tan conciso!", "Bueno, es un lenguaje basado en expresiones", piensas mientras hojeas el pull-request. Y te equivocas.

Kotlin es hermoso, pero traicionero. Te da herramientas potentes: funciones de ámbito, clases selladas, corrutinas. Y la misma cantidad de oportunidades para dispararte en el pie. En este artículo, analizaremos a qué prestar atención realmente durante un code review en Kotlin para que tu código no se convierta en un "monstruo de espaguetis" con efectos secundarios anulables.

Este artículo no es un manual de sintaxis. Es una lista de verificación práctica para el revisor que quiere ver no solo código funcional, sino un producto mantenible y seguro.

1. Null Safety: cuando "?" no es una panacea

Kotlin se enorgullece de su Null Safety. Y con razón. Pero en el code review debes verificar no solo la presencia de "!!", sino la lógica de trabajar con tipos anulables.

¿Qué debería ser una señal de alerta?

\n
• Uso descontrolado de "!!". Si un desarrollador usa !!, debe explicar en un comentario por qué ese valor está garantizado que no es nulo. Si no hay explicación, es un error.
\n
• Cadenas de safe call (?.) y elvis (?:). A menudo enmascaran errores lógicos. Ejemplo:
\n

// Problema: si user?.address?.city == null,\n// devolvemos silenciosamente "Unknown" sin registrar\nval city = user?.address?.city ?: "Unknown"\n

¿Cómo debería ser? Si null es una situación excepcional, usa requireNotNull o checkNotNull. Si es un comportamiento normal, regístralo.

val city = user?.address?.city\n    ?: run {\n        logger.warn("El usuario $userId no tiene ciudad")\n        "Unknown"\n    }\n

En un code review kotlin, pregunta siempre: "¿Y si este null es un error que estamos silenciando?"

2. Funciones de ámbito: let, apply, run — úsalas con criterio

Las funciones de ámbito son el poder de Kotlin. Pero en la práctica, veo que se usan como un martillo para cualquier clavo. La revisión de código Kotlin debe incluir el análisis: "¿Por qué aquí let y no run?"

Errores típicos:

\n
• let para verificar si es null. Está bien, pero no los anides unos dentro de otros:
\n

// Horrible\nuser?.let { u ->\n    address?.let { a ->\n        process(u, a)\n    }\n}\n\n// Bien\nif (user != null && address != null) {\n    process(user, address)\n}\n

\n
• apply para mutar un objeto. Ese es su propósito natural. Pero si usas apply dentro de let — alto. Eso huele a espagueti.
\n

Recuerda: with es para agrupar llamadas, also para efectos secundarios (registro), run para cálculos en contexto. No los confundas.

3. Inmutabilidad: var es una bandera roja

Kotlin promueve val. Y es maravilloso. Pero en la revisión de código Kotlin a menudo veo que los desarrolladores usan var donde podrían usar val con copia.

// Mal\nvar result = mutableListOf<Int>()\nitems.forEach { result.add(it * 2) }\n\n// Bien\nval result = items.map { it * 2 }\n

La regla es simple: si ves var, pregunta: "¿Por qué no val?" La mayoría de las veces la respuesta te sorprenderá: "No lo pensé".

La excepción es solo si la mutación es realmente necesaria (por ejemplo, en bucles con acumulación). Pero incluso allí a menudo se puede reemplazar con fold o reduce.

4. Clases selladas y when: no olvides el else

Las clases selladas son una alternativa elega