Code propre en Swift : comment écrire pour que vos collègues ne vous maudissent pas

Comment écrire du code propre en Swift : guide pour ceux qui se respectent et respectent leurs collègues

Chaque développeur a déjà ouvert un projet écrit six mois plus tôt et n'a pas compris ce qui s'y passait. Ou a reçu un commentaire en code review : « On aurait pu écrire ça plus simplement ». Ça vous parle ? Si oui, cet article est pour vous.

Le code propre en Swift n'est pas simplement un caprice de perfectionniste. C'est un outil qui fait gagner des heures de débogage et de stress. Quand vous écrivez proprement, vous accélérez non seulement votre travail, mais vous rendez aussi le projet transparent pour l'équipe. Voyons comment transformer votre code Swift en œuvre d'art.

Règle n°1 : Le nommage est primordial

Le péché le plus fréquent est de nommer une variable x ou temp. Ensuite, un autre développeur arrive et se demande : « Qu'est-ce que x ? Une coordonnée ? Une quantité ? »

En Swift, on donne des noms qui se lisent comme des phrases. Ce n'est pas seulement esthétique – cela permet de comprendre immédiatement ce que fait le code.

// Mauvais\nlet a = 5.0\nvar b = "John"\n\n// Bon\nlet discountRate = 5.0\nvar userName = "John"

Pour les fonctions et méthodes, la même règle s'applique. Le nom doit répondre à la question « Que fait cette méthode ? ». Utilisez des verbes à l'impératif :

// Mauvais\nfunc data() -> [String] { ... }\n\n// Bon\nfunc fetchUsers() -> [String] { ... }

Et si une fonction retourne une valeur booléenne, commencez le nom par is, has ou contains :

func isUserLoggedIn() -> Bool\nfunc hasValidEmail() -> Bool

Règle n°2 : Les optionnels ne sont pas des ennemis, mais des outils

Beaucoup de débutants ont peur des optionnels et essaient de s'en débarrasser à tout prix. Ils écrivent if let partout ou, pire encore, font du force-unwrap. Mais le code propre en Swift est un code qui gère nil en toute sécurité.

Souvenez-vous : ! est un cri d'aide. Utilisez-le uniquement si vous êtes absolument certain que la valeur n'est pas nil (par exemple, avec les IBOutlet).

// Code dangereux\nlet name = optionalName!\n\n// Version sécurisée\nguard let name = optionalName else {\n    return\n}\nprint(name)

Et pour les chaînes d'optionnels, utilisez ? et le nil-coalescing :

let userCity = user?.address?.city ?? "Inconnu"

Ce code ne plantera pas, même si user ou address s'avèrent être nil. Et il se lit comme une phrase normale : « La ville de l'utilisateur ou "Inconnu" ».

Règle n°3 : Les structures plutôt que les classes (quand c'est possible)

En Swift, il y a à la fois des classes et des structures. Mais beaucoup utilisent par habitude des classes partout. À tort. Les structures sont des value types, et elles sont plus sûres dans le code multithread. De plus, elles sont copiées, et non référencées, ce qui réduit le risque d'effets de bord.

Utilisez une structure si :

\n
• Vous devez stocker des données sans logique complexe
\n
• Il n'y a pas besoin d'héritage
\n
• L'objet ne doit pas être modifiable après sa création
\n

// Mieux : une structure\nstruct User {\n    let id: Int\n    var name: String\n}\n\n// Classe – seulement si l'héritage ou la sémantique de référence est nécessaire\nclass ViewController: UIViewController { ... }

D'ailleurs, Apple recommande d'utiliser des structures pour les modèles de données. C'est l'un des principes clés du code propre en Swift.

Règle n°4 : Les protocoles sont vos meilleurs amis

Les protocoles en Swift ne sont pas de simples interfaces. Ce sont un moyen de rendre le code flexible et testable. Au lieu de vous lier à une classe spécifique, travaillez via un protocole.

protocol NetworkServiceProtocol {\n    func fetchData(completion: @escaping (Result<Data, Error>) -> Void)\n}\n\nclass APIService: NetworkServiceProtocol { ... }\nclass MockService: NetworkServiceProtocol { ... }

Maintenant, vous pouvez facilement remplacer le service réel par un mock pour les tests. Et vous n'avez pas besoin de modifier le code aill