[Clean Code] Indentation… une histoire de bosses

Parler de l’indentation pourra vous sembler futile, voire même inutile : nos IDE sont en mesure de formater convenablement notre code… Inutile donc d’aborder le sujet.

Cependant, l’indentation reste un élément fondamental dans la compréhension du code : il permet d’arranger les blocs de code pour en faire ressortir des morceaux cohérents : on arrive ainsi a mieux s’extraire des détails (les sous blocs) et rester concentré sur un niveau précis d’abstraction (en général positionné au même niveau d’indentation).

Mais, au-delà de l’aspect organisationnel, la forme de votre code vous permet de détecter certains défauts de celui-ci. Je vous propose de recenser quelques unes de ces formes et les erreurs de design correspondantes.

Le dromadaire  & la complexité cyclomatique

Le dromadaire est un animal sympathique qui se caractérise principalement par son unique bosse.  Cela se présente dans votre code de la manière suivante :

Le dromadaire est symptomatique d’une complexité cyclomatique importante. La complexité cyclomatique est une métrique permettant d’évaluer la complexité d’un programme (ou d’une méthode) en mesurant le nombre de « chemins » possibles (des if, foreach, switch case,…). Plus vous aurez de chemins possibles, plus votre programme est jugé complexe donc difficile à maintenir et à faire évoluer.

Lorsque vous détectez du code dromadaire, cela signifie que vous empilez les blocs de code et donc que vous augmentez la complexité de votre méthode

Le chameau et le principe SRP :

Le chameau est le cousin germain du dromadaire : comme son cousin, il est sympathique, a une bonne tête, met en avant des problématiques de complexité cyclomatique MAIS PAS QUE… puisqu’il a deux bosses !

Dans le code suivant, on identifie bien deux bosses distinctes :

Ici, comme pour le dromadaire, chaque bosse contribuera à augmenter la complexité cyclomatique. De plus, les deux bosses vous permettent d’identifier deux phases du traitement de la méthode : le chargement des fichiers et le traitement de leur contenu… et c’est là où les bactéries attaquent que le principe SRP est violé.

Le principe SRP (single responsibility principle) dit qu’en POO, chaque objet doit avoir une responsabilité unique et que cette responsabilité doit être entièrement encapsulée dans une classe. Ici, nous avons clairement deux responsabilités qui sont couplées au sein de la même méthode et qui pourraient très bien se trouver dans deux méthodes distinctes (voire même deux classes si nécessaire) comme il suit :

On se retrouve avec deux méthodes (deux dromadaires en l’occurrence) qui sont spécialisées et ont une complexité cyclomatique plus basse.

Quand le dromadaire est fatigué… attention à vos niveaux d’abstraction :

Un dromadaire fatigué c’est, en gros, une bosse et un plat comme vous pouvez le voir sur l’exemple du code suivant :

Deux éléments qui se trouvent au même niveau d’indentation sont des étapes de traitement qui s’appliquent au même niveau d’abstraction. Dans le code précédent, on a une bosse qui précise le détail du chargement du fichier avec une précision allant jusqu’au caractère de chaque ligne. Dans la zone de plat, nous avons des étapes plus « haut niveau ». On transforme les éléments chargés (sans savoir précisément ce que cela signifie), on charge les éléments (où ? comment ?) et ensuite on fait le ménage et on notifie.

On a donc deux niveaux d’abstractions différents dans notre méthode :

• La bosse qui expose des détails d’une phase du traitement (extact)
• Des méthodes permettant d’identifier à plus haut niveau les étapes du traitement (transform, load, cleanup, notify)

Conserver les bons niveaux d’abstractions dans nos méthodes est important pour la lecture du code (cela évite à notre petit cerveau d’avoir à réorganiser notre compréhension du code) mais également pour avoir un design propre correspondant aux différents niveaux (pour simplifier notre code).

Conclusion

La forme de votre code, en plus de vous aider dans votre lisibilité, porte une information importante sur sa qualité ; vous pourrez facilement détecter des problèmes liés à :

• Une grande complexité cyclomatique
• Du couplage fonctionnel (SRP)
• Une mauvaise gestion de vos niveaux d’abstraction (mauvais design)