FR
RU
EN
ES
ZH
DE
PT
AR
HI
Comment ne pas se noyer dans le code des autres : introduction au code style Swift
\n\nImaginez : vous ouvrez une pull request d'un collègue, et là — let userName côtoie let UserName, les indentations sautent de 2 à 8 espaces, et les accolades sont tantôt sur la même ligne, tantôt sur une nouvelle. Familier ? Si votre équipe code en Swift, tôt ou tard vous serez confronté au chaos. Ou vous l'êtes déjà.
Travailler en équipe, ce n'est pas « comme ça m'arrange », mais « comme c'est compréhensible pour tous ». Le code style et les conventions pour Swift ne sont pas de la bureaucratie, mais une bouée de sauvetage. Ils font gagner des heures en code review, réduisent le nombre de bugs et rendent le code lisible même six mois plus tard. Dans cet article, je vais vous dire quelles règles fonctionnent vraiment, vous montrer des exemples en Swift et vous donner une checklist pour les mettre en place dans votre équipe. C'est parti !
\n\nPourquoi sans code style Swift devient un enfer
\n\nSwift est un langage jeune mais strict. Il pousse lui-même à la rigueur : optionnels, génériques, protocoles. Mais sans accords au sein de l'équipe, même une syntaxe parfaite ne sauvera rien. Voici trois raisons pour lesquelles le code style Swift est nécessaire pour chaque projet :
\n\n- \n
- Vitesse d'onboarding. Un nouveau développeur passe des jours à apprendre non pas la logique, mais « où se trouve quoi ». \n
- Code review. Au lieu de discuter de l'architecture, vous vous disputez sur les espaces. Une douleur familière ? \n
- Dette technique. Un style différent — une logique différente. Un jour, cela explosera en production. \n
Bonne nouvelle : les conventions Swift existent déjà. Il ne reste plus qu'à se mettre d'accord et à automatiser.
\n\nNommage : Swift Naming Convention
\n\nSwift est un langage avec une philosophie claire : « la clarté prime sur la brièveté ». Cela signifie que getUserData() est mauvais, tandis que fetchUserProfile() est bon. Passons en revue les règles principales de la Swift naming convention.
Variables et constantes
\n\nUtilisez le camelCase avec une minuscule. Nommez les entités de manière à ce qu'elles soient compréhensibles sans commentaire :
\n\n// Mauvais\nlet n = "Alice"\nlet u = 25\n\n// Bon\nlet userName = "Alice"\nlet userAge = 25\n\n// Excellent (avec le type)\nlet isActiveUser: Bool = true\nPour les variables booléennes, ajoutez les préfixes is, has, should — c'est une best practice Swift.
Fonctions et méthodes
\n\nLes fonctions doivent se lire comme une phrase. Verbe + nom — la règle d'or :
\n\n// Mauvais\nfunc change() { }\nfunc processData() { }\n\n// Bon\nfunc updateUserProfile() { }\nfunc validateEmailAddress() { }\n\n// Avec des paramètres — encore plus lisible\nfunc configureButton(withTitle title: String, color: UIColor) { }\nRemarque : le premier paramètre est souvent omis lors de l'appel, mais pour la lisibilité, il est préférable de le préciser explicitement. Cela fait partie du Swift code style guide d'Apple.
\n\nTypes et protocoles
\n\nClasses, structures, enum — PascalCase. Les protocoles aussi, mais essayez d'en faire des noms d'adjectifs :
\n\nclass UserManager { }\nstruct UserProfile { }\nenum NetworkError { }\n\nprotocol Configurable { }\nprotocol DataPersistable { }\nFormatage : respirez régulièrement
\n\nSujet de débats houleux — indentations, accolades, espaces. Mettons les points sur les i. Pour le code style Swift, je recommande de suivre la norme SwiftLint (nous y reviendrons).
\n\nAccolades
\n\nApple recommande de placer l'accolade ouvrante sur la même ligne (style K&R). L'accolade fermante — sur une nouvelle ligne :
\n\n// Correct\nif isLoggedIn {\n showDashboard()\n} else {\n showLoginScreen()\n}\n\n// Incorrect\nif isLoggedIn\n{\n showDashboard()\n}\nException — les closures. Là, les accolades peuvent être sur une seule ligne si le code est court :
\n\nlet sortedUsers = users.sorted { $0.age < $1.age }\n
Blogs
Book Recommendations
Lire aussi
