Accueil🇫🇷Chercher

Condition Yoda

Une condition Yoda est une condition de programmation informatique écrite de la forme "si 42 est le prix", alors que dans le langage courant on aurait tendance à dire "si le prix est 42".

Lorsque l'on veut comparer une partie variable avec une valeur constante, la condition Yoda consiste à écrire la valeur constante à gauche. Cette pratique évite des erreurs d'étourderie dans certains langages informatiques. Lire le code à voix haute vous donnera un ordre des mots inhabituel, ressemblant au personnage de Yoda dans Star Wars. Les conditions Yoda font partie des règles de codage de WordPress[1] et de Symfony[2].

Exemples

Pour la condition suivante :

if ( valeur == 42 ) { /* ... */ }
// Lire : "Si la valeur est égale à 42, alors ..."

la condition Yoda correspondante serait :

if ( 42 == valeur ) { /* ... */ }
// Lire : "Si 42 est égale à la valeur, alors ..."

La constante est écrite à la gauche de l'opérateur de comparaison, et le nom de la variable à droite. Cela ressemble à l'ordre Objet-Sujet-Verbe[3] qu'utilise Yoda.

Avantages

Dans les langages de programmation qui utilisent un seul signe égal (=) pour l'affectation mais pas pour la comparaison (C, C++, Java, etc.), il est facile de confondre l'expression qui enregistre une constante dans une variable (variable = 42) avec celle qui teste l'égalité d'une variable avec une constante (variable == 42). En utilisant une condition Yoda, l'erreur est détectée dès la compilation puisqu'il est impossible de modifier une constante.

// Sans condition Yoda
if (variable = 42) { /* ... */ }
// Compile correctement : la condition sera toujours vraie, et ce que contenait la variable est écrasé.
// Avec condition Yoda
if (42 = variable) { /* ... */ }
// Ne compile pas :
//  error: lvalue required as left operand of assignment
//  if (42 = variable) { /* ... */ }
//         ^

Les conditions Yoda permettent aussi d'éviter des déréférencements de pointeurs nuls.

// Sans condition Yoda
String myString = null;
if (myString.equals("foobar")) { /* ... */ }
// Compile mais lève une NullPointerException à l'exécution
// Avec condition Yoda
String myString = null;
if ("foobar".equals(myString)) { /* ... */ }
// Ne lève pas d'exception, la condition est fausse comme attendue.

Critiques

Les critiques des conditions Yoda considèrent que la perte de lisibilité qu'elles induisent est un inconvénient qui est loin d'être compensé par les bénéfices.

Dans certains langages de programmation, comme Swift, les expressions d'affectation ne renvoient aucune valeur[4], ce qui rend sémantiquement incorrect l'utilisation de celles-ci comme conditions. Dans d'autres langages, comme Python, les affectations sont des instructions au lieu d'être des expressions[5], ce qui rend syntaxiquement incorrect l'utilisation de celles-ci comme conditions. Les erreurs syntaxiques et sémantiques empêchent la compilation ou l'interprétation du programme et obligent le programmeur à corriger son erreur. Dans les langages où le résultat des conditions doit avoir un type particulier (booléen) comme en Java, l'expression d'affectation ne peut être utilisée incorrectement comme condition que si l'expression est de ce type .

En outre, plusieurs compilateurs, comme GCC[6] ou Clang, peuvent afficher un avertissement en présence de code comme if (variable = 42), ce qui permet d'alerter le programmeur. Il est alors inutile de recourir à des conditions Yoda pour se prémunir d'une confusion entre affectation et test d'égalité.

De plus, cette forme n'est pas utilisable pour les comparaisons entre deux variables, où la présence d'une variable à gauche de l'opérateur de comparaison est inévitable.

Par ailleurs, l'utilisation des conditions Yoda pour éviter les déréférencements de pointeur nul peut également être vue comme dangereuse, les pointeurs nuls étant alors masqués et susceptibles de produire des erreurs beaucoup plus loin dans le programme. En particulier, cela rend le débogage des programmes souffrant de ce genre de problème plus fastidieux.

Enfin, une attention particulière doit être portée à l'écriture des conditions Yoda, certaines propriétés jugées intuitives (comme la symétrie de l'égalité) n'étant parfois pas vérifiées. Ainsi, en C++, la comparaison d'une chaîne de caractères wchar_t littérale avec une variable de type CComBSTR sera correcte si elle est écrite cbstrMessage == L"Hello" mais provoquera une erreur de compilation si elle est écrite L"Hello" == cbstrMessage, faute de surcharge convenable de l'opérateur d'égalité[7].

Voir aussi

Références
  1. (en) « PHP Coding Standards, Yoda Conditions », sur https://make.wordpress.org/core/handbook/
  2. (en) « Coding Standards, Structure », sur https://symfony.com/doc/
  3. (en) Geoffrey K. Pullum, « Yoda's Syntax the Tribune Analyzes; Supply More Details I Will! », sur http://itre.cis.upenn.edu/~myl/languagelog/, Language Log, (consulté le ) : « One way to look at Yoda's syntax is that it shows signs of favoring OSV syntax (Object-Subject-Verb) as the basic order in the simple clause. »
  4. (en) Apple, « The Swift Programming Language, Basic Operators » (consulté le ) : « Unlike the assignment operator in C and Objective-C, the assignment operator in Swift does not itself return a value. »
  5. (en) « The Python Language Reference, Simple statements » (consulté le ) : « Assignment statements are used to (re)bind names to values and to modify attributes or items of mutable objects. »
  6. (en) « Using the GNU Compiler Collection (GCC), Options to Request or Suppress Warnings » (consulté le ) : « Warn if parentheses are omitted in certain contexts, such as when there is an assignment in a context where a truth value is expected, or when operators are nested whose precedence people often get confused about. »
  7. (en) Microsoft, « CComBSTR Class, CComBSTR::operator == » (consulté le )

Liens externes
Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.