'AND' vs '&&' en tant qu'opérateur

J'ai une base de code où les développeurs ont décidé d'utiliser ANDet ORau lieu de &&et ||.

Je sais qu'il y a une différence dans la priorité des opérateurs ( &&va avant and), mais avec le cadre donné ( PrestaShop pour être précis) ce n'est clairement pas une raison.

Quelle version utilisez-vous? Est andplus lisible que &&? Ou n'y a-t-il aucune différence?

Si vous utilisez ANDet OR, vous finirez par vous faire tromper par quelque chose comme ceci:

$this_one = true;
$that = false;

$truthiness = $this_one and $that;

Vous voulez deviner ce qui $truthinessest égal?

Si vous avez dit false... bzzzt, désolé, faux!

$truthinessci-dessus a la valeur true. Pourquoi? =a une priorité plus élevée que and. L'ajout de parenthèses pour montrer l'ordre implicite rend cela plus clair:

($truthiness = $this_one) and $that

Si vous l'avez utilisé à la &&place de anddans le premier exemple de code, cela fonctionnerait comme prévu et le serait false.

Comme indiqué dans les commentaires ci-dessous, cela fonctionne également pour obtenir la valeur correcte, car les parenthèses ont une priorité plus élevée que =:

$truthiness = ($this_one and $that)

Selon la façon dont il est utilisé, il peut être nécessaire et même pratique. http://php.net/manual/en/language.operators.logical.php

// "||" has a greater precedence than "or"

// The result of the expression (false || true) is assigned to $e
// Acts like: ($e = (false || true))
$e = false || true;

// The constant false is assigned to $f and then true is ignored
// Acts like: (($f = false) or true)
$f = false or true;

Mais dans la plupart des cas, cela ressemble plus à un goût de développeur, comme chaque occurrence de cela que j'ai vue dans le cadre de CodeIgniter comme @Sarfraz l'a mentionné.

Pour des raisons de sécurité, je garde toujours entre parenthèses mes comparaisons et je les espace. De cette façon, je n'ai pas à me fier à la priorité des opérateurs:

if( 
    ((i==0) && (b==2)) 
    || 
    ((c==3) && !(f==5)) 
  )

La priorité diffère entre && et et (&& a une priorité plus élevée que and), ce qui cause de la confusion lorsqu'il est combiné avec un opérateur ternaire. Par exemple,

$predA && $predB ? "foo" : "bar"

renverra une chaîne alors que

$predA and $predB ? "foo" : "bar"

renverra un booléen .

Depuis anda une priorité inférieure à celle que =vous pouvez utiliser dans l'affectation de condition:

if ($var = true && false) // Compare true with false and assign to $var
if ($var = true and false) // Assign true to $var and compare $var to false

Permettez-moi d'expliquer la différence entre «et» - «&&» - «&».

"&&" et "et" sont tous deux des opérations ET logiques et font la même chose, mais la priorité de l'opérateur est différente.

La priorité (priorité) d'un opérateur spécifie comment "étroitement" il lie deux expressions ensemble. Par exemple, dans l'expression 1 + 5 * 3, la réponse est 16 et non 18 car l'opérateur de multiplication ("*") a une priorité plus élevée que l'opérateur d'addition ("+").

Les mélanger ensemble en une seule opération pourrait vous donner des résultats inattendus dans certains cas, je recommande toujours d'utiliser &&, mais c'est votre choix.

D'un autre côté, "&" est une opération ET au niveau du bit . Il est utilisé pour l'évaluation et la manipulation de bits spécifiques dans la valeur entière.

Par exemple, si vous le faites (14 et 7), le résultat serait 6.

7   = 0111
14  = 1110
------------
    = 0110 == 6

Quelle version utilisez-vous?

Si les normes de codage pour la base de code particulière pour laquelle j'écris du code spécifient l'opérateur à utiliser, je vais certainement l' utiliser. Sinon, et le code dicte qui doit être utilisé (pas souvent, peut être facilement contourné) alors je vais l'utiliser. Sinon, probablement && .

Est «et» plus lisible que «&&»?

Est-il plus lisible pour vous ? La réponse est oui et non en fonction de nombreux facteurs dont le code autour de l'opérateur et même de la personne qui le lit!

|| il y a ~ différence?

Oui. Voir les opérateurs logiques pour ||et les opérateurs au niveau du bit pour ~.

Je suppose que c'est une question de goût, bien que (à tort) les mélanger puisse provoquer des comportements indésirables:

true && false || false; // returns false

true and false || false; // returns true

Par conséquent, en utilisant && et || est plus sûr car ils ont la plus haute priorité. En ce qui concerne la lisibilité, je dirais que ces opérateurs sont assez universels.

MISE À JOUR : À propos des commentaires disant que les deux opérations retournent false ... eh bien, en fait, le code ci-dessus ne renvoie rien, je suis désolé pour l'ambiguïté. Pour clarifier: le comportement dans le second cas dépend de la façon dont le résultat de l'opération est utilisé. Observez comment la priorité des opérateurs entre en jeu ici:

var_dump(true and false || false); // bool(false)

$a = true and false || false; var_dump($a); // bool(true)

La raison en $a === trueest que l'opérateur d'affectation a priorité sur tout opérateur logique, comme cela est déjà très bien expliqué dans d'autres réponses.

Voici un petit contre-exemple:

$a = true;
$b = true;
$c = $a & $b;
var_dump(true === $c);

production:

bool(false)

Je dirais que ce type de faute de frappe est beaucoup plus susceptible de causer des problèmes insidieux (de la même manière que =vs ==) et est beaucoup moins susceptible d'être remarqué que adn/ rotypos qui signalera comme des erreurs de syntaxe. Je trouve également et / ou est beaucoup plus facile à lire. FWIW, la plupart des frameworks PHP qui expriment une préférence (la plupart ne le font pas) spécifient et / ou. Je n'ai également jamais rencontré de cas réel et non artificiel où cela aurait eu de l'importance.

Un autre bel exemple utilisant des ifinstructions sans =opérations d'affectation.

if (true || true && false); // is the same as:
if (true || (true && false)); // TRUE

et

if (true || true AND false); // is the same as:
if ((true || true) && false); // FALSE

car ANDa une priorité inférieure et donc ||une priorité plus élevée.

Celles-ci sont différentes dans les cas de true, false, falseet true, true, false. Voir https://ideone.com/lsqovs pour un exemple détaillé.