Fonctions

Le Clean Code nécessite d’appliquer certaines règles concernant le formatage des fonctions. La première d’entre elles : elles doivent être courtes. De manière générale, plus une fonction est courte, meilleure elle est. Ce point est d’autant plus vrai qu’il va souvent de pair avec le SPR (Single Principle Responsability, ou principe de responsabilité unique).

Ce SPR est issu des pratiques du SOLID, mais est extrêmement présent et implanté dans l’écriture des fonctions. Ce principe stipule qu’une chose (ici une fonction) ne doit faire qu’une seule chose. De la sorte, si vous avez besoin d’afficher le résultat d’un calcul, vous allez créer deux fonctions : une pour réaliser le calcul, et l’autre pour l’afficher. Cette pratique consiste en la séparation des commandes (calculs) et des demandes (affichage). Ainsi le respect de ce principe vous aidera grandement dans la réduction de la taille de vos fonctions.

Les fonctions n’échappent pas à la règle de décroissance : les fonctions sont déclarées dans le même ordre qu’elles sont appelées par la suite. Ce point peut vous sembler évident, mais il reste toujours bon de le rappeler.

Toujours dans l’esprit des règles de base du Clean Code, les noms doivent être explicites et descriptifs. Par ailleurs, moins vous utilisez d’arguments, mieux vous vous en porterez. De la sorte les fonctions nidaliques sont les fonctions idéales. Petite séance de vocabulaire au passage : “nidalique” signifie “zéro argument”. Lorsqu’une fonction ne dispose que d’un seul argument, elle est dite monadique. Dyadique pour 2 arguments ou Triadique pour 3 arguments. À partir du moment où plusieurs arguments sont utilisés, on parle de fonction polyadique. Revenons maintenant à l’essentiel : moins il y a d’arguments, plus votre code sera considéré comme “propre”.

Autre point qui peut sembler niais de prime abord : il faut éviter les répétitions au sein des fonctions… Alors il en va de même pour l’ensemble du code me direz-vous, mais je suis à peu près sûr qu’il est possible de trouver du code dupliqué au sein de votre projet, même au sein d’une seule et unique fonction…

Une autre pratique permettant d’obtenir un Clean Code est d’extraire les blocs try/catch dans des fonctions spécifiques. Considérez cette méthode dès l’utilisation d’un tel bloc. Dans la même idée, il est important de préférer traiter les exceptions aux codes erreurs. Trop de codes sont conditionnés à des codes erreurs, alors que les exceptions sont une manière bien plus élégante et complète de les traiter.

Le point suivant peut se trouver quelques fois discuté, d’autant plus en fonction du contexte dans lequel vous évoluez. Évitez les structures en Switch. Ces structures sont - je vous l’accorde - mises en place par les langages de programmation, donc si elles existent, rien n’interdit de les utiliser… Oui, sauf que leur modification peut s’avérer (très) problématique en fonction de la manière employée pour les déclarer ! De la sorte, en contexte orienté objet, il est préférable de les placer au sein d’un pattern Factory. Dans un contexte procédural, préférez changer de structure pour du conditionnel classique. Si vous ne pouvez réellement pas faire autrement, employé un dérivé du pattern Factory au sein d’une fonction dédiée pour limiter la casse (placez bien cette fonction dans un fichier séparé dénommé Factory pour vous repérer plus facilement !).

Pour finir sur les fonctions, deux éléments restent à prendre en compte. Le premier : évitez les effets cachés ou secondaires : ce sont les effets non renseignés dans le nom de la fonction, ou non attendus à la suite de son appel. Enfin, essayez de vous tenir à un seul retour (return) par fonction. Plus vous augmentez le nombre de retours possibles, plus vous vous éloignez de votre Clean Code en accroissant la difficulté d’identification d’une signature unique. Par ailleurs les termes génériques “continue” pour continuer à exécuter un code, “break” pour arrêter un code, ou encore “goto” pour envoyer sur un autre endroit du code sont à proscrire absolument. Ce genre de fonctionnalités sont offertes par les langages afin de vous permettre de réaliser des modifications simplement et rapidement, mais leur utilisation est représentative d’un code mal conçu, et donc loin d’un Clean Code.