Clean Code en Kotlin : 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 Kotlin : principes et exemples pour débutants

\n\n

Le code propre (Clean Code) n'est pas simplement un terme à la mode, mais une compétence fondamentale pour tout développeur. En langage Kotlin, qui allie concision et puissance, écrire un code lisible et maintenable devient particulièrement important. Dans cet article, nous analyserons les principes clés du Clean Code appliqués à Kotlin, fournirons des exemples pratiques et montrerons comment éviter les erreurs typiques. Ce contenu est destiné aux développeurs débutants qui souhaitent écrire du code professionnel dès le premier jour.

\n\n

1. Nommage des variables, fonctions et classes

\n\n

Un bon nommage est la base d'un code propre. Le nom doit répondre aux questions : « Qu'est-ce que c'est ? » et « À quoi ça sert ? ». En Kotlin, on utilise le camelCase pour les variables et les fonctions, et le PascalCase pour les classes et les objets.

\n\n

Mauvais exemple :

val x = 5\nfun calc(a: Int, b: Int): Int {\n    return a * b + 10\n}

\n\n

Bon exemple :

val maxRetryCount = 5\nfun calculateTotalPrice(basePrice: Int, tax: Int): Int {\n    return basePrice + tax\n}

\n\n

Règles clés :

Évitez les abréviations — remplacez usr par user, et calc par calculate.
Utilisez des verbes pour les fonctions — getUser(), sendEmail(), validateInput().
Les variables booléennes doivent être nommées avec les préfixes is, has, can — isActive, hasPermission.
Évitez les informations superflues — userList est mieux que listOfUsersFromDatabase.

\n\n

2. Principes SOLID en Kotlin

\n\n

SOLID est un ensemble de cinq principes de programmation orientée objet qui aident à créer des systèmes flexibles et faciles à maintenir. Examinons-les avec des exemples en Kotlin.

\n\n

Single Responsibility (responsabilité unique)

Une classe ne doit avoir qu'une seule raison de changer. Séparez la logique en petites classes spécialisées.

\n\n

Mauvais exemple :

class UserManager {\n    fun saveUser(user: User) { /* sauvegarde en BDD */ }\n    fun sendEmail(user: User) { /* envoi d'email */ }\n    fun printReport(user: User) { /* impression du rapport */ }\n}

\n\n

Bon exemple :

class UserRepository {\n    fun save(user: User) { /* sauvegarde en BDD */ }\n}\n\nclass EmailService {\n    fun send(user: User) { /* envoi d'email */ }\n}\n\nclass ReportPrinter {\n    fun print(user: User) { /* impression du rapport */ }\n}

\n\n

Open/Closed (ouvert/fermé)

Les classes doivent être ouvertes à l'extension, mais fermées à la modification. Utilisez des interfaces et l'héritage.

\n\n

interface Shape {\n    fun area(): Double\n}\n\nclass Circle(val radius: Double) : Shape {\n    override fun area() = Math.PI * radius * radius\n}\n\nclass Rectangle(val width: Double, val height: Double) : Shape {\n    override fun area() = width * height\n}\n\n// On peut maintenant ajouter de nouvelles formes sans modifier le code existant\n

\n\n

Liskov Substitution (substitution de Liskov)

Les objets des sous-classes doivent pouvoir remplacer les objets de la classe de base sans altérer la logique. En Kotlin, cela est particulièrement pertinent lors du travail avec les collections et l'héritage.

\n\n

open class Bird {\n    open fun fly() = "Vole"\n}\n\nclass Penguin : Bird() {\n    override fun fly() = throw UnsupportedOperationException("Les pingouins ne volent pas")\n}\n// Ceci viole le principe — il est préférable de déplacer la "capacité à voler" dans une interface séparée\n

\n\n