C'est quoi une fonction propre ?

Introduction

Dans son livre Clean Code, Uncle Bob nous donne plusieurs étapes pour coder des fonctions propres, en voici 10.

Bien entendu, il est important de rappeler que ce sont des règles, et qu'il y a des exceptions à ces règles.
Mais il faut les connaître pour pouvoir les appliquer.

1. Plus c'est court, plus c'est bon

Première caractéristique d'une fonction propre : elle doit être courte.

Uncle Bob a écrit :

Les fonctions doivent être courtes. Les fonctions doivent être encore plus courtes que cela.

Pour lui, une fonction ne doit pas dépasser 20 lignes. Il y a des exceptions, mais elles sont rares.

2. Mollo sur la touche "Tab"

Concernant l'indentation, il est recommandé de ne pas dépasser 2 niveaux d'indentation.
Et si on dépasse, il faut extraire le code dans une autre fonction.
L'indentation est un bon indicateur de la complexité d'une fonction.

Les "if" et les "else" devraient renvoyés vers d'autres fonctions.
Tout ceci permet de rendre le code plus lisible.

3. Monotache

Toujours selon Uncle Bob, une fonction doit faire une seule chose et la faire bien.
Si elle fait plus d'une chose, elle est trop longue. Si elle ne peut pas être nommée sans utiliser le mot "et", elle est trop longue.

Uncle Bob a écrit à ce sujet :

Functions should do one thing. They should do it well. They should do it only.

4. Une fonction c'est comme un ascenceur

Une fonction doit être comme un ascenceur, elle doit faire monter ou descendre d'un niveau d'abstraction.

5. Un joli petit nom

Une fonction doit avoir un nom qui explique ce qu'elle fait.

Si on est obligé de mettre un commentaire pour expliquer ce qu'elle fait, c'est qu'elle n'a pas un bon nom.
On sait qu'on travaille sur une bonne fonction quand on peut lire son nom et comprendre ce qu'elle fait.
Mais par dessus tout, il faut qu'elle fasse ce qu'elle dit.

6. Les paramètres

Le nombre idéal de paramètres est de 0.
Après 0 paramètre, l'autre nombre idéal est de 1.

Mais on devrait éviter autant que possible les fonctions avec 3 paramètres.
Et une fonction ne devrait jamais avoir plus de 3 paramètres.
Et parfois, les regrouper dans un objet permet d'ajouter de la clarté.

7. Les flags

Les flags sont des variables booléennes qui disent à la fonction de faire une chose ou une autre.

C'est une mauvaise pratique car ça veut dire que la fonction fait plus d'une chose.
Il faut donc séparer la fonction en deux.

8. Les effets secondaires

Une fonction ne devrait pas avoir d'effets secondaires.
Elle ne devrait pas modifier une variable globale, ni un paramètre.

Un effet secondaire crée un couplage temporal entre la fonction et son environnement.

9. Command Query Separation

C'est à dire que les fonctions devraient soit modifier l'état d'un objet, soit renvoyer des informations sur l'état de l'objet, mais pas les deux.

10. Les exceptions

Il faut privilégier les exceptions aux codes d'erreurs.
Les exceptions permettent de séparer le code de gestion des erreurs du code métier.
Et elles permettent de remonter l'erreur jusqu'à la couche la plus haute.

Lorsqu'on retourne un code erreur, il faut que le code appelant sache quoi faire avec, cela oblige à gérer immédiatement l'erreur.

Conclusion

Voici donc les 10 premières étapes pour coder des fonctions propres selon Uncle Bob.
Bien entendu, il y en a d'autres, et elles seront abordées dans un prochain article.