Clean Code en Swift : principes et exemples pour débutants

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Clean Code en Swift : principes et exemples pour débutants

\n\n

Tout 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\n

1. Nommage : variables, constantes et fonctions

\n\n

Le 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\n

Mauvais exemple :

\n
var d: Double = 3.14\nvar arr = [String]()\nfunc calc(a: Double, b: Double) -> Double {\n    return a * b\n}
\n\n

Bon exemple (Clean Code) :

\n
let piValue: Double = 3.14159\nvar userNames: [String] = []\nfunc calculateRectangleArea(width: Double, height: Double) -> Double {\n    return width * height\n}
\n\n

Rè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
\n\n

2. Fonctions : une tâche — une fonction

\n\n

Le 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\n

Mauvais exemple : la fonction fait tout à la fois

\n
func 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\n

Bon exemple : division en petites fonctions

\n
func 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\n

Conseil : Si vous ne trouvez pas un nom court pour une fonction, il y a de fortes chances qu'elle fasse trop de choses.

\n\n

3. Commentaires : moins c'est mieux, mais avec précision

\n\n

Dans 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\n

Commentaire redondant (mauvais) :

\n
// Incrémente le compteur de 1\ncounter += 1
\n\n

Commentaire 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\n

Règles pour les commentaires :

\n
    \n
  • N'écrivez pas l'évidence — le code se lit de lui-même.
  • \n
  • Utilisez // MARK: - pour

Blogs

Book Recommendations