Clean Code en Swift: principios y ejemplos para iOS/macOS

Clean Code en Swift: por qué lo necesita un desarrollador iOS

Cada desarrollador se ha enfrentado a una situación en la que el código antiguo se convierte en "espagueti" al cabo de un mes. En el mundo de Swift, donde los proyectos crecen rápidamente, mantener la limpieza del código se vuelve crítico. Clean Code no es solo estética, sino una herramienta que ahorra horas de depuración y simplifica la adición de nuevas funciones. En este artículo, analizaremos los principios clave de Clean Code aplicados a Swift, con ejemplos reales para iOS y macOS.

1. Nomenclatura: la legibilidad ante todo

Una nomenclatura correcta es la base del código limpio. En Swift, donde las API suelen ser autodocumentadas, los nombres deficientes son la principal fuente de confusión.

Ejemplo incorrecto:

class DataManager {    func getData() -> [String: Any] {        // ...    }}

Ejemplo correcto:

class UserProfileFetcher {    func fetchUserProfile(for userID: String) -> Result<UserProfile, NetworkError> {        // ...    }}

• Use verbos para los métodos (fetch, update, delete).
• Evite abreviaturas — vc, btn, str — son cosa del pasado.
• Las variables booleanas deben leerse como afirmaciones: isLoggedIn, hasNetworkConnection.

2. Funciones: pequeñas y con un solo propósito

En Swift, donde los closures y la programación funcional son populares, es fácil dejarse llevar y escribir una función monolítica. El principio de responsabilidad única (Single Responsibility) funciona aquí al 100%.

Ejemplo incorrecto:

func processUserData(user: User) {    // Validación    if user.email.isEmpty { return }    // Guardar en CoreData    CoreDataStack.shared.save(user)    // Enviar al servidor    APIClient.shared.send(user)    // Actualizar UI    DispatchQueue.main.async {        self.tableView.reloadData()    }}

Ejemplo correcto (división en funciones pequeñas):

func processUserData(user: User) {    guard validateUser(user) else { return }    saveUserLocally(user)    sendUserToServer(user)    updateUI()}

private func validateUser(_ user: User) -> Bool {    return !user.email.isEmpty}

private func saveUserLocally(_ user: User) {    CoreDataStack.shared.save(user)}

private func sendUserToServer(_ user: User) {    APIClient.shared.send(user)}

private func updateUI() {    DispatchQueue.main.async {        self.tableView.reloadData()    }}

Regla de las 20 líneas: si la función no cabe en la pantalla, divídala. Cada función debe hacer solo una acción.

3. SOLID en Swift: ejemplos prácticos

Los principios SOLID no son una abstracción, sino herramientas de trabajo. Analicemos dos clave para iOS.

Principio de abierto/cerrado (Open/Closed)

Las clases deben estar abiertas para la extensión, pero cerradas para la modificación. En lugar de modificar una clase ya hecha, use protocolos.

protocol PaymentProcessor {    func process(amount: Double, currency: String) -> Bool}

class ApplePayProcessor: PaymentProcessor {    func process(amount: Double, currency: String) -> Bool {        // Lógica de Apple Pay        return true    }}

class StripeProcessor: PaymentProcessor {    func process(amount: Double, currency: String) -> Bool {        // Lógica de Stripe        return true    }}

// Ahora agregar un nuevo método de pago es simplemente crear una nueva clase, sin tocar las antiguas.

Principio de sustitución de Liskov (Liskov Substitution)

Las subclases no deben romper la lógica del padre. Un error típico es sobrescribir un método cambiando el contrato.

class Vehicle {    func startEngine() {        print("Engine started")    }}

class ElectricCar: Vehicle {    override func startEngine() {        // Violación: el