Conditions Yoda

Un petit post est dédié à tous les fans de Star Wars et de Java/JavaRush en l'honneur du 40ème anniversaire de la sortie de l'épisode V de la saga star ! Parfois, on peut trouver beaucoup de choses intéressantes sur Internet, et l'autre jour, je suis tombé sur une pratique de programmation plutôt amusante à première vue appelée Conditions Yoda . En bref, les conditions Yoda (également la notation Yoda) sont un style de programmation dans lequel les deux parties de l'expression de comparaison familière dans les instructions conditionnelles sont inversées :

if (5 == a) {
    // do something
}

Ce style peut être utilisé dans les langages avec une syntaxe de type C, le plus souvent dans des expressions avec ifet while.

if (0 == variable) {
    // do something
}

while (false == endingCondition) {
    // do something
}

Pourquoi déplacer l’expression constante vers la gauche de l’opérateur de comparaison ? Supposons une situation hypothétique dans laquelle, après un visionnage marathon des neuf six parties de la saga, nous nous sommes assis, sans dormir, pour écrire du code pour notre projet favori et avons écrit ce qui suit :

void checkNumber(int a)
{
    if (a = 13) // Здесь-то и появляется так называемый unexpected behavior!
    {
        printf("Number is 13");
    }
}

Dans ce cas, chaque fois que vous exécuterez le programme, vous recevrez la chaîne Number is 13", quel que soit l'argument passé аà la méthode checkNumber(int a). Ce n’est pas ce à quoi nous nous attendions ! Des erreurs logiques peuvent survenir assez souvent chez les programmeurs débutants (croyez-moi, je SAIS). Mais au stade de la compilation, un code comme 13 = a produira une erreur que nous ne négligerons certainement pas, puisque la valeur entière est une constante et, par conséquent, ne peut pas changer (se transformer en « a »).

Il y a des avantages et des inconvénients à utiliser les conditions de Yoda.

Côté lumière :

1. Empêcher l'affectation à une variable lorsque notre objectif est la comparaison.

2. Résoudre le problème du « comportement nul » dangereux ( NullPointerException) // exemples tirés de Wikipédia

Sans Yoda :

String myString = null;
if (myString.equals("foobar")) { /* ... */ }
// This causes a NullPointerException in Java

Avec Yoda :

String myString = null;
if ( "foobar".equals(myString) ) { // Результат - Ложь
   /* не выполняется */
}

Côté obscur:

1. La lisibilité du code pour les personnes qui examineront votre code devient plus complexe, augmentant la charge sur la perception du code.
2. Portée étroite, seule la comparaison d'égalité ou la comparaison avec une constante est utilisée, en vérifiant la valeur nulle.
3. De nombreux compilateurs « voient » déjà des erreurs de ce type et avertissent à l'avance de la présence d'une erreur potentielle.

Une alternative à la notation Yoda peut être les tests unitaires. À l’époque de l’Ancienne République, on disait qu’effectuer de bons tests garantirait que le code serait sans erreur et ne ferait que ce pour quoi il a été écrit. Quelles pratiques utiles connaissez-vous ? Partagez vos connaissances dans les commentaires ! Et écrivez également votre épisode préféré ! Et que la Force soit avec vous !