Résumé
Une méthode qui peut échouer pour une ou plusieurs raisons et répond par un booléen perd l’information la plus utile qui soit: le pourquoi. L’appelant reçoit false et ne sait pas quoi faire ensuite, réessayer, prévenir l’utilisateur, traduire en statut HTTP, compenser. Écrire la cause dans un log n’aide pas, parce que les logs ne sont pas une API: ils peuvent être absents, filtrés, non corrélés ou hors de portée.
L’habitude a une histoire. Le C n’avait pas de type booléen avant C99; les fonctions renvoyaient un int, zéro pour faux, n’importe quoi d’autre pour vrai, et toute une culture des codes de retour s’est construite autour, zéro pour le succès et négatif pour l’erreur, ou moins un plus errno. Le type est arrivé, la culture est restée, et elle nous a suivis dans des langages qui avaient tous les moyens de faire mieux.
Les alternatives n’ont rien d’exotique. En C, des codes d’erreur nommés sur lesquels l’appelant peut faire un switch, ou un masque de bits quand plusieurs conditions peuvent être vraies à la fois, comme dans la validation d’un formulaire. Ailleurs, un type Result qui porte le succès ou l’échec avec un code d’erreur et un message, des exceptions métier et techniques typées dans l’esprit du domain-driven design, ou simplement une énumération. Le style compte moins que la règle: exposer une cause sur laquelle l’appelant peut agir.
Mes règles tiennent en peu de mots. Éviter le retour booléen, le bannir là où c’est possible; renvoyer un code d’erreur, un Result, un type d’erreur, une énumération ou un masque de bits; laisser les logs aider au diagnostic sans jamais tenir lieu de contrat. Choisissez le style qui vous convient, mais ne choisissez pas l’anti-pattern.
Idées clés
- Un retour booléen cache le pourquoi: l’appelant ne peut pas choisir entre réessayer, prévenir l’utilisateur, traduire en statut HTTP ou compenser.
- Les logs ne sont pas une API; ils peuvent être absents, filtrés, non corrélés ou inaccessibles, et les parser est fragile et hors contrat.
- L’habitude date du C d’avant C99, quand il n’y avait pas de type booléen; le type est arrivé, la culture du code de retour est restée.
- Codes d’erreur nommés ou masque de bits en C, type Result, exceptions typées ou énumération ailleurs: n’importe quel style vaut mieux que l’anti-pattern.
- Les tests ne peuvent affirmer une cause précise que si le contrat en porte une.
Pourquoi j’ai écrit cet article
Pour nommer un anti-pattern ordinaire, la méthode qui répond false sans dire pourquoi, en remonter l’origine au C d’avant C99, et donner à l’appelant les alternatives, code d’erreur nommé, Result, exception typée ou énumération, qui lui rendent une cause sur laquelle agir.