Les principes de

base du Clean Code

Luco Ny Aina Yannick

Ramaromanana (lucoram)
Expert Scripter @ Beenox (Activision)
Résumé

- Qu’est ce que le “Clean Code” ?

- Pourquoi est-ce que le “Clean Code” est important ?
- Comment faire pour avoir un “Clean Code”?
- Le “Clean Code Checklist”
- Les “code reviews”
- Le “refactoring”
Qu’est ce que le “Clean Code” ?
Qu’est ce que le “Clean Code” ? (1/4)
Qu’est ce que le “Clean Code” ? (2/4)
Qu’est ce que le “Clean Code” ? (3/4)
- Un code facilement compréhensible, extensible et maintenable
- Un code qui n’est pas “messy” (sale, pas propre)

- Et qu’est-ce qu’un code pas propre?

- Des noms de variables sans signification
- Des commentaires inutiles
- De longues fonctions dans de longues classes
- Grand nombre de paramètres des fonctions
- Grand nombre d’imbrications
- Des codes dupliqués partout
- Des modules fortement couplés (code spaghetti)
- …
Qu’est ce que le “Clean Code” ? (4/4)
- Un code propre est aussi:
- Un code qui se lit comme le journal
- Un code que le lecteur comprend au premier coup d’oeil

“Clean code is a code that is written by someone who cares”

- Michael Feathers
Author of the book “Working Effectively with Legacy Code” (Prentice Hall, 2004)
Pourquoi est-ce que le “Clean Code” est important ?
 Pourquoi le “Clean Code” est important ? (1/4)

- Pourquoi les programmeurs écrivent du code pas

propre?
- Manque d’expérience (juniors, débutants)
- Pression, délais trop courts, mauvaise estimation
- Manque de compréhension des besoins
- Abus d’utilisation des “best practices”
- Peur de casser des choses
- Différents styles de codage parmi les développeurs
- Pour s’aligner aux standards déjà établis
- “Un code fonctionnel a plus de valeur qu’un code
propre”
- “C’est déjà un énorme spaghetti de toute façon !”
- “Mon travail n’est pas de nettoyer le code !”
- PERFORMANCE
 Pourquoi le “Clean Code” est important ? (2/4)

- Quelles sont les conséquences d’un code pas propre?

- Accumulation de la dette technique
- Le temps de maintenance augmente avec le temps
- La productivité des développeurs diminue avec le temps
- Les développeurs préfèrent travailler sur de nouvelles fonctionnalités
- La réutilisation du code est presque inexistante
- L’assimilation du projet devient difficile
- Le système devient difficile à comprendre
- Risque élevé de démission des développeurs
- Le système devient instable
- Le nombre de bugs augmente drastiquement
- La collaboration devient difficile
- Le temps de recherche dans le projet augmente
Pourquoi le “Clean Code” est important ? (3/4)

- Le clean code:
- Facilite la collaboration
- est plus facile à lire et
comprendre
- encourage à écrire et
garder un code propre
- réduit le risque de bugs
- réduit le temps de
recherche

Clean Code : A Handbook of Agile Software Craftsmanship |

Robert. C Martin
Pourquoi le “Clean Code” est important ? (3/4)

- Améliore la productivité
- Augmente l'extensibilité
- Augmente la réutilisation
- Facilite la correction des bugs
- La maintenance devient un
plaisir
- La peur de casser le système
disparaît
Comment faire pour avoir un “Clean Code”?
Comment faire pour avoir un “Clean Code”? (1/3)

- On ne peut pas:
- “The best code is no code at all” - Jeff Atwood
- “The code easiest to maintain is the code that was never written.” - RobertGalanakis
Comment faire pour avoir un “Clean Code”? (2/3)

- Mais nous pouvons essayer en suivant et en appliquant:

- Les principes de bases du clean code
- Les conventions de langages/d'équipe
- Les techniques de POO et COO (OOP, OOD)
- Les Design Patterns
- Le refactoring et améliorations progressives
Comment faire pour avoir un “Clean Code”? (3/3)

- Les principes de bases du clean code:

- DRY: Don’t Repeat Yourself
- KISS: Keep It Simple, Stupid Sassy! -
- YAGNI: You Ain’t Gonna Need It
- SoC: Separation of Concerns

- Technique OOP et OOD, Design Patterns

- S.O.L.I.D
- GRASP: General Responsibility Assignment Software Patterns
Factory, Controller, Strategy, Observer, Visitor, Delegation, Loose coupling, High
Cohesion, Polymorphism, …
“Always code as if the guy who ends
up maintaining reviewing your code
will be a violent psychopath who
knows where you live. Code for
readability.”

- John F. Woods
A game programmer
Le “Clean Code Checklist”
Le minimum que nous devons faire
 Le “Clean Code Checklist” (1/12)
Noms de variables/fonctions/classes significatifs (meaningful names)

Code auto-documenté (self-commenting code)

Lignes vides/espacement (empty lines)

Taille des fonctions (functions length, SoC: separation of concerns)

Nombre d’arguments des fonctions (functions number of arguments)

Indentation (nesting/cyclomatic complexity)

DRY (Don’t Repeat Yourself)

OCP (Open Close Principle)

Tailles des classes (classes length, SRP: Single Responsibility Principle)

Heritage et Polymorphism (Inheritance and Polymorphism)

 Le “Clean Code Checklist” (2/12)
Noms significatifs (meaningful names)

A FAIRE A ÉVITER
nom descriptif nom trop court

nommage cohérent nom trop long

en anglais abréviations

même nom pour la même “type” préfixes

chose

nom positif pour les “magic numbers”,

booléens “hardcoded values”

utiliser les “in-built utils

functions”

nommer les conditions

complexes
Le “Clean Code Checklist” (2.1/12)
Noms significatifs (meaningful names)
Le “Clean Code Checklist” (3/12)
Code auto-documenté (self-commenting code)

Utilisez les commentaires seulement pour des

algorithmes/lignes de code complexes!
 Le “Clean Code Checklist” (4/12)
Lignes vides/espacement (empty lines)

Ajouter des lignes vides:

- entre les fonctions
- pour séparer des lignes similaires/relatives
- autour des blocs de même indentation
- autour de lignes qu’on veut emphaser
(return, asserts, prints, func calls, …)
Le “Clean Code Checklist” (5/12)
Taille des fonctions (functions length, SoC: separation of concerns)

Taille moyenne des fonctions: ~15 lignes

Taille maximum: 40 lignes
 Le “Clean Code Checklist” (6/12)
Nombre d’arguments des fonctions (functions number of arguments)

- 3 arguments par fonctions au max

- regrouper dans des arrays/structs/objects
- changer en variables d’instances/globales
Le “Clean Code Checklist” (7/12)
Indentation (nesting/cyclomatic complexity)
https://www.perforce.com/blog/qac/what-cyclomatic-complexity

- 3 niveaux d’indentations au max

- exporter les blocs internes dans des fonctions
privées
- utiliser le “Guard Clause Pattern”
Le “Clean Code Checklist” (8/12)
DRY (Don’t Repeat Yourself) (1/3)

N'abusez pas du “ternary condition” quand même!

 Le “Clean Code Checklist” (9/12)
DRY (Don’t Repeat Yourself) (2/3)

“Exportation et Paramétrisation” : Idéal

pour plusieurs lignes de code qui se
répètent/sont similaires
Le “Clean Code Checklist” (10/12)
DRY (Don’t Repeat Yourself) (3/3)

Ce qu’on voit ici:

- DRY
- SoC
- OCP
- Guard Clause
 Le “Clean Code Checklist” (11/12)
Tailles des classes (classes length, SRP: Single Responsibility Principle)

- ~60 lignes en moyenne, max 120 lignes:

- Diviser en plusieurs composants (ex POJO) (Composition)
- Utiliser des classes utilitaires (DRY)
- Détacher les propriétés optionnelles (Aggregation)
- Utiliser l'héritage/polymorphism (DRY)
 Le “Clean Code Checklist” (12/12)
Heritage et Polymorphism (Inheritance and Polymorphism)

Ce qu’on voit ici:

- DRY
- SoC
- SRP

Head First Object-Oriented Analysis and Design

 Les “code reviews”
- Ce que c’est:
- Assurer la qualité du code avant
soumission
- Apprentissage pour les moins
expérimentés
- Partage d'idée/connaissances
- Quick/Delayed pair programming
- Suivi de l’avancement du travail

- Ce que ce n’est pas:

- Jugement [du travail] de la
personne qui a fait le code
- Plateforme de débat

https://github.com/marketplace/category/code-review
 Le “refactoring”
- Ce que c’est:
- Nettoyage/amélioration de code
- Amélioration de performance
- “Paiement” des dettes
techniques
- N’affecte pas (et ne doit pas) les
fonctionnalités existantes
- Application du “Incremental
Refinement”

- Ce que ce n’est pas:

- Ajout de nouvelles
fonctionnalités
- Amélioration de fonctionnalités
- Corrections de bugs
 Références
- Livres:
- Clean Code : Handbook of Agile Software Craftsmanship :
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
- Head First Design Patterns : http://shop.oreilly.com/product/9780596007126.do
- Head First Object Oriented Analysis and Design :
http://shop.oreilly.com/product/9780596008673.do
- Web:
- https://en.wikipedia.org/wiki/SOLID
- https://en.wikipedia.org/wiki/Technical_debt
- https://blog.codinghorror.com/the-broken-window-theory/
- https://blog.codinghorror.com/the-best-code-is-no-code-at-all/
- https://blog.knoldus.com/mastering-the-art-of-writing-maintainable-and-scalable-code-a-guide-t
o-clean-code-principles/
- https://www.startupinstitute.com/blog/2016-05-24-if-you-want-to-know-how-to-write-clean-co
de-accept-that-it-will-be-messy-at-first
 Merci!
Questions?