Código limpio en Swift: cómo escribir para que tus colegas no te maldigan

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

Cómo escribir código limpio en Swift: guía para quienes se respetan a sí mismos y a sus colegas

\n\n

Cada desarrollador al menos una vez ha abierto un proyecto escrito hace seis meses y no ha podido entender qué está pasando allí. O ha recibido en la revisión de código un comentario: «Esto se podría haber escrito más simple». ¿Te suena? Si es así, este artículo es para ti.

\n\n

El código limpio en Swift no es solo un capricho de perfeccionista. Es una herramienta que ahorra horas de depuración y nervios. Cuando escribes de manera ordenada, no solo aceleras tu trabajo, sino que también haces el proyecto transparente para el equipo. Analicemos cómo convertir tu código Swift en una obra de arte.

\n\n

Regla n.º 1: La nomenclatura es lo primero

\n\n

El pecado más común es nombrar una variable x o temp. Luego llega otro desarrollador y se pregunta: «¿Qué es x? ¿Una coordenada? ¿Una cantidad?»

\n\n

En Swift se acostumbra dar nombres que se lean como oraciones. Esto no solo es estético, sino que ayuda a entender de inmediato qué hace el código.

\n\n
// Mal\nlet a = 5.0\nvar b = "John"\n\n// Bien\nlet discountRate = 5.0\nvar userName = "John"
\n\n

Para funciones y métodos aplica la misma regla. El nombre debe responder a la pregunta «¿Qué hace este método?». Usa verbos en modo imperativo:

\n\n
// Mal\nfunc data() -> [String] { ... }\n\n// Bien\nfunc fetchUsers() -> [String] { ... }
\n\n

Y si la función devuelve un valor booleano, comienza el nombre con is, has o contains:

\n\n
func isUserLoggedIn() -> Bool\nfunc hasValidEmail() -> Bool
\n\n

Regla n.º 2: Los opcionales no son enemigos, sino herramientas

\n\n

Muchos principiantes temen a los opcionales e intentan deshacerse de ellos a cualquier precio. Escriben if let en todas partes o, peor aún, fuerzan el desempaquetado. Pero el código limpio en Swift es código que trabaja de forma segura con nil.

\n\n

Recuerda: ! es un grito de auxilio. Úsalo solo si estás absolutamente seguro de que el valor no es nil (por ejemplo, al trabajar con IBOutlet).

\n\n
// Código peligroso\nlet name = optionalName!\n\n// Opción segura\nguard let name = optionalName else {\n    return\n}\nprint(name)
\n\n

Y para cadenas de opcionales usa ? y nil-coalescing:

\n\n
let userCity = user?.address?.city ?? "Desconocido"
\n\n

Este código no fallará, incluso si user o address resultan ser nil. Y se lee como una oración normal: «La ciudad del usuario o "Desconocido"».

\n\n

Regla n.º 3: Estructuras en lugar de clases (donde sea posible)

\n\n

En Swift existen tanto clases como estructuras. Pero muchos por costumbre usan clases en todas partes. Y es una lástima. Las estructuras son tipos de valor (value types) y son más seguras en código concurrente. Además, se copian, no se referencian, lo que reduce el riesgo de efectos secundarios.

\n\n

Usa una estructura si:

\n
    \n
  • Necesitas almacenar datos sin lógica compleja
  • \n
  • No hay necesidad de herencia
  • \n
  • El objeto no debe ser mutable después de su creación
  • \n
\n\n
// Mejor una estructura\nstruct User {\n    let id: Int\n    var name: String\n}\n\n// Clase solo si se necesita herencia o semántica de referencia\nclass ViewController: UIViewController { ... }
\n\n

Por cierto, Apple recomienda usar estructuras para modelos de datos. Este es uno de los principios principales del código limpio en Swift.

\n\n

Regla n.º 4: Los protocolos son tus mejores amigos

\n\n

Los protocolos en Swift no son solo interfaces. Son una forma de hacer el código flexible y testeable. En lugar de atarte a una clase concreta, trabaja a través de un protocolo.

\n\n
protocol NetworkServiceProtocol {\n    func fetchData(completion: @escaping (Result<Data, Error>) -> Void)\n}\n\nclass APIService: NetworkServiceProtocol { ... }\nclass MockService: NetworkServiceProtocol { ... }
\n\n

Ahora puedes reemplazar fácilmente el servicio real por un mock para las pruebas. Y no necesitas cambiar el código en otro

Blogs

Book Recommendations