Le readonly en C# : détail insignifiant ou bonne pratique essentielle ? Certains te diront que « le readonly, c’est du détail ». Je vais être cash : c’est faux. Et ce genre de raccourci peut plomber la qualité de ton code. Quand j’ai commencé à utiliser l’injection de dépendance en C#, j’ai fait l’erreur classique : négliger ce petit mot-clé. Je me disais : « Tant que ça compile, c’est bon. » Je ne voyais pas l’impact sur la robustesse ou la maintenabilité. Résultat : → Je laissais des dépendances modifiables après construction → Je me retrouvais avec des bugs difficiles à traquer → Mes classes perdaient leur contrat d’immutabilité… sans que je m’en rende compte Pourquoi ? Parce que j’étais trop concentré sur le fonctionnel, pas assez sur la solidité. Ce que je ne savais pas à l’époque : readonly n’est pas juste un décorateur, c’est une garantie contractuelle : → Il protège contre les réassignations accidentelles → Il communique une intention claire : « ça ne bougera pas. » → Il rend ton code plus lisible, plus fiable Et surtout : il fait partie des bonnes pratiques d’architecture. La vérité, c’est que négliger readonly, ça punit les devs qui veulent aller vite... trop vite. Mais quand tu l’adoptes systématiquement ? C’est un filet de sécurité incroyable. → Tu protèges tes dépendances contre les modifications → Tu communiques ton intention aux autres devs → Tu évites des bugs subtils → Tu construis des classes plus solides sans effort supplémentaire Ne te laisse pas avoir par les raccourcis en code review. Le readonly, ce n’est pas du "nice-to-have". C’est une discipline d’ingénieur·e. Ceux qui veulent coder vite... mais bien. Et toi ? Quelle est la "petite" bonne pratique que tu as d’abord négligée, avant de comprendre son importance ? #DotNet #CSharp #CleanCode #RetourDexperience #DevLife #SoftwareEngineering #Architecture #CodeResponsable