Clean Code en Swift : principes et exemples pour iOS/macOS

Clean Code sur Swift : pourquoi c’est nécessaire pour un développeur iOS

Chaque développeur a déjà été confronté à une situation où un ancien code se transforme en "spaghetti" au bout d’un mois. Dans le monde Swift, où les projets grandissent rapidement, maintenir la propreté du code devient crucial. Clean Code n’est pas qu’une question d’esthétique, c’est un outil qui économise des heures de débogage et simplifie l’ajout de nouvelles fonctionnalités. Dans cet article, nous allons analyser les principes clés de Clean Code appliqués à Swift, avec des exemples concrets pour iOS et macOS.

1. Nommage : la lisibilité avant tout

Un bon nommage est la base d’un code propre. En Swift, où les API sont souvent auto-documentées, les mauvais noms sont la principale source de confusion.

Mauvais exemple :

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

Bon exemple :

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

• Utilisez des verbes pour les méthodes (fetch, update, delete).
• Évitez les abréviations — vc, btn, str — c’est dépassé.
• Les variables booléennes doivent se lire comme des affirmations : isLoggedIn, hasNetworkConnection.

2. Fonctions : petites et avec un seul objectif

En Swift, où les closures et la programmation fonctionnelle sont populaires, il est facile de se laisser emporter et d’écrire une fonction monolithique. Le principe de responsabilité unique (Single Responsibility) fonctionne ici à 100%.

Mauvais exemple :

func processUserData(user: User) {    // Validation    if user.email.isEmpty { return }    // Sauvegarde dans CoreData    CoreDataStack.shared.save(user)    // Envoi au serveur    APIClient.shared.send(user)    // Mise à jour de l’UI    DispatchQueue.main.async {        self.tableView.reloadData()    }}

Bon exemple (division en petites fonctions) :

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()    }}

Règle des 20 lignes : si une fonction ne tient pas sur un écran — divisez-la. Chaque fonction ne doit faire qu’une seule action.

3. SOLID en Swift : exemples pratiques

Les principes SOLID ne sont pas une abstraction, mais des outils de travail. Analysons deux principes clés pour iOS.

Principe d’ouverture/fermeture (Open/Closed)

Les classes doivent être ouvertes à l’extension, mais fermées à la modification. Au lieu de modifier une classe existante, utilisez des protocoles.

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

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

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

// Maintenant, ajouter un nouveau moyen de paiement — il suffit de créer une nouvelle classe sans toucher aux anciennes.

Principe de substitution de Liskov (Liskov Substitution)

Les sous-classes ne doivent pas casser la logique du parent. Une erreur typique est de redéfinir une méthode en modifiant le contrat.

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

class ElectricCar: Vehicle {    override func startEngine() {        // Violation : la voiture électrique ne démarre pas de moteur traditionnel        // Cela casse le contrat de la classe parente    }}