Bits rapides de logique conditionnelle : exigences et cas extrêmes

Nous développons des compétences en matière de lecture et d'écriture de conditions logiques au fil du temps, et les nouvelles fonctionnalités du langage peuvent nous fournir de nouvelles solutions. Mais toutes les solutions ne se valent pas. Jetons un coup d'œil rapide à un exemple.

Installation

Disons que nous avons une propriété qui peut exister à plusieurs endroits et que nous souhaitons donner la priorité à l'instance imbriquée. Voici quelques solutions possibles :

// Option A: Ternary
const setting = config.user ? config.user.setting : config.setting;

// Option B: Optional Chaining and Nullish Coalescing
const setting = config.user?.setting ?? config.setting;

// Option C: Destructuring and Nullish Coalescing
const { setting } = config.user ?? config;

Repérez les différences

Ceux-ci semblent assez similaires en termes de fonctionnalités, mais il existe des différences subtiles. En fonction de nos exigences commerciales ou de la conception des données, certains d'entre eux peuvent provoquer des bugs.

Jetez un œil aux trois options et voyez si vous pouvez identifier les différents scénarios dans lesquels le résultat sera différent. Quelles hypothèses faisons-nous avec chaque version ?

Analyse de l'opérateur

Tout d’abord, considérons les opérateurs spécifiques en jeu.

• Ternaire - utilise une vérification véridique pour décider quelle expression est utilisée.
• Chaînage facultatif - renvoie un élément indéfini si l'objet est nullish mais pas s'il est simplement faux.
• Coalescence nulle - utilise la deuxième expression si la première est nulle.

Pas nul

L'opérateur ternaire se démarque, ici. Dans la plupart des cas, il se comportera de la même manière lorsque nous parlons d'objets. Les différences se résument à ce que nous attendons des valeurs lorsque les choses ne fonctionnent pas.

Un objet non attribué est généralement indéfini ou nul. Mais si notre projet utilise false ou « Pas encore un objet ! », l'hypothèse faite avec le ternaire pourrait produire des résultats indésirables. C'est cependant un cas limite assez improbable.

Comprendre l'intention

Si nous ignorons le scénario improbable du « non-objet », les options A et C sont fondamentalement identiques.

1. Si config.user existe, récupérez config.user.setting.
2. Sinon, récupérez config.setting.

L'option B fait quelque chose de différent.

1. Si config.user.setting existe, utilisez-le.
2. Sinon, récupérez config.setting.

La différence est faible mais concerne directement des exigences ou une décision de conception technique : Retournons-nous au config.setting si l'utilisateur est manquant, ou seulement si le user.setting est manquant ?

Les deux sont des possibilités valables, mais si nous faisons une mauvaise hypothèse, nous pouvons nous retrouver avec rien lorsque nous nous attendons à la valeur par défaut, ou quelque chose lorsque nous n'attendons rien.

Conclusion

Il n’y a pas de « bonne réponse » ici autre que de demander quel est l’objectif. Nous avons besoin de plus de contexte. Demander des éclaircissements sur ces questions peut paraître pédant aux membres du projet, mais ces petits détails peuvent créer des bugs très subtils si nous n'avons pas d'alignement sur les attentes.

Il pourrait y avoir une bonne réponse pour ce projet ou pour une entreprise entière. Nous pourrions même utiliser plusieurs options dans un seul projet ; un pour se concentrer sur la valeur ; un autre pour se concentrer sur la structure. Peut-être que personne n’a pris en compte ces différences. Peut-être que l'équipe pense qu'elle s'est alignée alors qu'elle ne l'est pas.

Vous ne saurez pas si vous ne demandez pas.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!