ES
RU
EN
ZH
FR
DE
PT
AR
HI
Cómo no ahogarse en código ajeno: introducción al code style Swift
\n\nImagina: abres un pull request de un colega, y allí — let userName convive con let UserName, las sangrías saltan de 2 a 8 espacios, y las llaves están unas veces en la misma línea y otras en una nueva. ¿Te suena? Si tu equipo escribe en Swift, tarde o temprano te enfrentarás al caos. O ya lo has hecho.
Trabajar en equipo no es sobre «cómo me conviene a mí», sino sobre «cómo es claro para todos». El code style y las convenciones para Swift no son burocracia, sino un salvavidas. Ahorran horas en code review, reducen la cantidad de errores y hacen que el código sea legible incluso después de seis meses. En este artículo, te contaré qué reglas realmente funcionan, mostraré ejemplos en Swift y te daré una lista de verificación para implementar en tu equipo. ¡Vamos allá!
\n\nPor qué sin code style Swift se convierte en un infierno
\n\nSwift es un lenguaje joven, pero estricto. Él mismo impulsa a la pulcritud: opcionales, genéricos, protocolos. Pero sin acuerdos dentro del equipo, ni siquiera la sintaxis ideal salva. Aquí hay tres razones por las que Swift code style es necesario en cada proyecto:
\n\n- \n
- Velocidad de onboarding. Un nuevo desarrollador pasa días aprendiendo no la lógica, sino «dónde está qué cosa». \n
- Code review. En lugar de discutir la arquitectura, discuten sobre espacios. ¿Dolor familiar? \n
- Deuda técnica. Diferente estilo — diferente lógica. Un día explotará en producción. \n
La buena noticia: las convenciones Swift ya están inventadas. Solo queda acordarlas y automatizarlas.
\n\nNomenclatura: Swift Naming Convention
\n\nSwift es un lenguaje con una filosofía clara: «la claridad es más importante que la brevedad». Esto significa que getUserData() es malo, y fetchUserProfile() es bueno. Analicemos las reglas principales de Swift naming convention.
Variables y constantes
\n\nUsa camelCase con minúscula inicial. Nombra las entidades de manera que se entiendan sin comentario:
\n\n// Mal\nlet n = "Alice"\nlet u = 25\n\n// Bien\nlet userName = "Alice"\nlet userAge = 25\n\n// Excelente (con tipo)\nlet isActiveUser: Bool = true\nPara variables booleanas, añade prefijos is, has, should — esto es una best practice Swift.
Funciones y métodos
\n\nLas funciones deben leerse como una oración. Verbo + sustantivo es la regla de oro:
\n\n// Mal\nfunc change() { }\nfunc processData() { }\n\n// Bien\nfunc updateUserProfile() { }\nfunc validateEmailAddress() { }\n\n// Con parámetros — aún más legible\nfunc configureButton(withTitle title: String, color: UIColor) { }\nNota: el primer parámetro a menudo se omite al llamar, pero para la legibilidad es mejor indicarlo explícitamente. Esto es parte de la Swift code style guide de Apple.
\n\nTipos y protocolos
\n\nClases, estructuras, enum — PascalCase. Los protocolos también, pero procura que sean nombres de adjetivos:
\n\nclass UserManager { }\nstruct UserProfile { }\nenum NetworkError { }\n\nprotocol Configurable { }\nprotocol DataPersistable { }\nFormato: respira uniformemente
\n\nTema de guerras santas — sangrías, llaves, espacios. Pongamos los puntos sobre las íes. Para Swift code style recomiendo seguir el estándar de SwiftLint (más sobre esto después).
\n\nLlaves
\n\nApple recomienda poner la llave de apertura en la misma línea (estilo K&R). La de cierre, en una nueva línea:
\n\n// Correcto\nif isLoggedIn {\n showDashboard()\n} else {\n showLoginScreen()\n}\n\n// Incorrecto\nif isLoggedIn\n{\n showDashboard()\n}\nExcepción — closures. Allí las llaves pueden estar en una misma línea si el código es corto:
\n\nlet sortedUsers = users.sorted { $0.age < $1.age }\n
Blogs
Book Recommendations
Leer también
