C-SHARP - 7.3 Suppression des effets secondaires

Un effet secondaire, c'est tout changement qu'une fonction provoque en dehors de sa propre portée : modifier une variable globale, écrire dans un fichier, mettre à jour une propriété d'un objet partagé. Ce n'est pas mauvais en soi, mais accumulé sans discipline, c'est l'une des causes principales de bugs difficiles à reproduire. Cette vidéo explique pourquoi limiter ces effets rend le code plus facile à déboguer.

Une fonction pure est l'opposé : elle prend des entrées, retourne un résultat et ne touche à rien d'autre. Pour des entrées identiques, elle produit toujours la même sortie. En C#, on tend vers ce style en évitant de muter les paramètres reçus, en privilégiant le retour de nouvelles valeurs plutôt que la modification en place, et en limitant l'accès aux variables statiques mutables. LINQ illustre parfaitement cette philosophie : Where, Select, OrderBy ne modifient jamais la collection source.

L'immuabilité va dans le même sens. Une instance immuable ne peut pas être modifiée après sa création ; on retourne à la place une nouvelle instance reflétant le changement souhaité. C'est exactement ce que fait string, et c'est ce que proposent les record introduits en C# 9. Adopter ces réflexes améliore la lisibilité, simplifie les tests unitaires et facilite le raisonnement sur le code, notamment en environnement multi-thread.

En pratique, la règle ne consiste pas à éliminer tout effet secondaire (impossible : il faut bien afficher, sauvegarder, envoyer une requête) mais à les concentrer dans des couches identifiées, et à garder le reste du code purement fonctionnel. Cette séparation entre « calcul pur » et « effets observables » est l'un des leviers les plus efficaces pour réduire la dette technique.