Clean Code en Swift : principes et exemples pour débutants
\n\nTout développeur iOS ou macOS rencontre tôt ou tard un problème : un code qui fonctionnait parfaitement hier devient illisible aujourd'hui. Ce n'est pas la faute du langage Swift — c'est le résultat d'une négligence des principes du Clean Code. Un code propre n'est pas qu'une question d'esthétique. C'est le fondement de la maintenabilité d'un projet, de la réduction du temps de débogage et d'un travail d'équipe confortable. Dans cet article, nous allons analyser les principes clés du Clean Code avec des exemples en Swift qui vous aideront à écrire un code compréhensible non seulement par l'ordinateur, mais aussi par les humains.
\n\n1. Nommage : variables, constantes et fonctions
\n\nLe premier principe et le plus important — le nom doit répondre à la question « Pourquoi ? », et non « Comment ? ». En Swift, grâce au typage strict, vous pouvez omettre le type dans le nom, mais pas l'intention.
\n\nMauvais exemple :
\nvar d: Double = 3.14\nvar arr = [String]()\nfunc calc(a: Double, b: Double) -> Double {\n return a * b\n}\n\nBon exemple (Clean Code) :
\nlet piValue: Double = 3.14159\nvar userNames: [String] = []\nfunc calculateRectangleArea(width: Double, height: Double) -> Double {\n return width * height\n}\n\nRègles de nommage en Swift :
\n- \n
- Utilisez le camelCase pour les variables et les fonctions. \n
- Évitez les abréviations (
btn→submitButton). \n - Pour les variables booléennes, utilisez les préfixes
is,has,should(par exemple,isUserLoggedIn). \n - Les noms de fonctions doivent commencer par un verbe :
fetchData(),saveToCache(). \n
2. Fonctions : une tâche — une fonction
\n\nLe principe de responsabilité unique (Single Responsibility) ne s'applique pas seulement aux classes, mais aussi aux fonctions. Si une fonction fait plus d'une chose — il faut la diviser.
\n\nMauvais exemple : la fonction fait tout à la fois
\nfunc processUserData(user: User) {\n // Validation\n guard user.email.contains("@") else { return }\n // Sauvegarde en base de données\n Database.shared.save(user)\n // Envoi d'une notification\n NotificationCenter.default.post(name: .userDidRegister, object: nil)\n // Mise à jour de l'interface utilisateur\n DispatchQueue.main.async {\n self.label.text = "Bienvenue, \\(user.name)"\n }\n}\n\nBon exemple : division en petites fonctions
\nfunc registerUser(_ user: User) {\n guard validateUser(user) else { return }\n saveUserToDatabase(user)\n postRegistrationNotification()\n updateUI(for: user)\n}\n\nprivate func validateUser(_ user: User) -> Bool {\n return user.email.contains("@") && !user.name.isEmpty\n}\n\nprivate func saveUserToDatabase(_ user: User) {\n Database.shared.save(user)\n}\n\nprivate func postRegistrationNotification() {\n NotificationCenter.default.post(name: .userDidRegister, object: nil)\n}\n\nprivate func updateUI(for user: User) {\n DispatchQueue.main.async {\n self.welcomeLabel.text = "Bienvenue, \\(user.name)"\n }\n}\n\nConseil : Si vous ne trouvez pas un nom court pour une fonction, il y a de fortes chances qu'elle fasse trop de choses.
\n\n3. Commentaires : moins c'est mieux, mais avec précision
\n\nDans le Clean Code, les commentaires sont un signe de code mal conçu. Un bon code doit se documenter lui-même. Cependant, il existe des exceptions : la logique métier complexe, le travail avec du code legacy ou les API publiques.
\n\nCommentaire redondant (mauvais) :
\n// Incrémente le compteur de 1\ncounter += 1\n\nCommentaire utile (bon) :
\n// Utilisation de Decimal pour éviter les erreurs d'arrondi lors du travail avec des devises\nlet price = Decimal(string: "19.99") ?? .zero\n\nRègles pour les commentaires :
\n- \n
- N'écrivez pas l'évidence — le code se lit de lui-même. \n
- Utilisez
// MARK: -pour