Condition Yoda

Un article de Wikipédia, l'encyclopédie libre.

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[modifier | modifier le code]

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[modifier | modifier le code]

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éfencements 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[modifier | modifier le code]

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.

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é.

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[modifier | modifier le code]

Références[modifier | modifier le code]

  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 22 décembre 2014) : « 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 10 août 2016) : « 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 10 août 2016) : « 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 10 août 2016) : « 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 10 août 2016)

Liens externes[modifier | modifier le code]