Ne pas utiliser de booléens

Utilisez des enums à la place.

Avec des déclarations générales comme celle-ci, il y a toujours des exceptions. Bien que, en général, je crois que l’utilisation des enums est souvent un meilleur choix par rapport aux booléens, sauf si vous avez vraiment besoin de compresser vos données en un seul bit physique.

Lisibilité

Récemment, j’ai rencontré un appel de fonction dans notre code où j’ai mis au défi mon équipe de nommer les arguments pour de l’argent, et malheureusement, j’ai gardé mon argent. Cela ressemblait à quelque chose comme ceci :

Évidemment, la lisibilité pourrait s’améliorer considérablement en ayant une annotation en ligne :

Bien que, comme nous le voyons ici, vous avez besoin soit d’un processus de révision de code rigoureux ou d’un linter, ou simplement de compter sur les développeurs faisant preuve de diligence. Quelque chose comme ceci serait beaucoup plus lisible :

Remarquez la différence entre les enums Exclusive et Flags. L’un est un enum exclusif (c’est-à-dire que chaque élément ne peut avoir qu’une seule des valeurs booléennes) et l’autre est un ensemble de drapeaux de masque de bits.

Typage explicite

Pourquoi voudriez-vous un typage explicite ? Imaginez rester éveillé tard pour corriger un bug et appeler cette fonction. Si vous êtes comme moi, il y a une forte probabilité que vous croisiez les yeux et passiez true/false aux mauvais endroits, appelant true au lieu de false. Vos tests auraient dû avoir toutes les permutations des booléens pour attraper ce problème. Et bonne chance pour repérer le problème même si vos tests échouaient.

Avec la version enum de l’API, vous ne pouvez pas appeler accidentellement true. Le compilateur ou l’interpréteur devrait hurler assez fort dans ce cas.

Si votre langage de programmation le permet, utilisez des types de masque de bits explicites au lieu de booléens. Cela garantira que le site d’appel ne puisse pas passer accidentellement les mauvais drapeaux.

Comportement orienté et extensibilité

Chaque fois que j’étais sur le point d’utiliser des booléens et que je reculais pour envisager d’utiliser des enums comme alternative, je me retrouvais souvent à passer en revue les cas d’utilisation réels, ou les comportements et états de l’application. Il est facile de simplement ajouter un autre booléen à ce moment-là sans considérer le cas d’utilisation réel ou le comportement de l’API. Regardons à nouveau notre API Flag; la signature booléenne est :

Supposons que nous ayons une nouvelle donnée appelée Details, et que nous voulions renvoyer ces Details. Cependant, nous devons être compatibles avec les appelants existants, et ne renvoyer les drapeaux que s’ils l’indiquent explicitement. Alors mettons à jour la signature de notre API :

Un problème cependant : les drapeaux proviennent en fait des détails. En d’autres termes, nous devons valider que si Details est true, l’appelant doit également définir Flag sur true, et documenter quelque part (en supposant que vos appelants lisent la documentation) :

Imaginez avoir trois enums ou plus qui sont co-dépendants, nous aurons soudainement besoin d’une grande matrice de compatibilité. Voyons comment nous pouvons étendre la version enum de cette API :

La seule chose que nous devons faire est d’ajouter une nouvelle option dans notre enum Flag :

L’appelant ne peut tout simplement pas passer la mauvaise chose !

Résumé

Avec chaque base de code, il y a toujours un juste équilibre avec lequel on devrait « sur-ingénier ». Cependant, je pense que le surcoût pour utiliser des enums au lieu de booléens est assez faible, et les avantages que les enums offrent valent l’effort.

Copyright 2024, Steven Luu. Les opinions exprimées ici sont les miennes.

Source de l’article