'AND' vs '&&' come operatore

Ho una base di codice in cui gli sviluppatori hanno deciso di utilizzare ANDe ORinvece di &&e ||.

So che c'è una differenza nella precedenza degli operatori ( &&va prima and), ma con il framework dato ( PrestaShop per la precisione) non è chiaramente un motivo.

Che versione stai usando? È andpiù leggibile di &&? O non c'è differenza?

Se usi ANDe OR, alla fine sarai inciampato in qualcosa del genere:

$this_one = true;
$that = false;

$truthiness = $this_one and $that;

Vuoi indovinare ciò che è $truthinessuguale?

Se hai detto false... bzzzt, scusa, sbaglio!

$truthinesssopra ha il valore true. Perché? =ha una precedenza superiore a and. L'aggiunta di parentesi per mostrare l'ordine implicito rende questo più chiaro:

($truthiness = $this_one) and $that

Se hai usato &&invece che andnel primo esempio di codice, funzionerebbe come previsto ed è false.

Come discusso nei commenti seguenti, questo funziona anche per ottenere il valore corretto, poiché le parentesi hanno una precedenza più alta di =:

$truthiness = ($this_one and $that)

A seconda di come viene utilizzato, potrebbe essere necessario e persino utile. 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;

Ma nella maggior parte dei casi sembra più una cosa di gusto per gli sviluppatori, come ogni evenienza di questo che ho visto nel framework CodeIgniter come @Sarfraz ha menzionato.

Per sicurezza, parentizzo sempre i miei confronti e li distacco. In questo modo, non devo fare affidamento sulla precedenza dell'operatore:

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

La precedenza differisce tra && e e (&& ha una precedenza più alta di e), qualcosa che provoca confusione quando combinato con un operatore ternario. Per esempio,

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

restituirà una stringa mentre

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

restituirà un valore booleano .

Poiché andha una precedenza inferiore a quella =che puoi usare nell'assegnazione delle condizioni:

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

Lasciami spiegare la differenza tra “e” - “&&” - "&".

"&&" e "e" sono entrambi operazioni logiche AND e fanno la stessa cosa, ma la precedenza dell'operatore è diversa.

La precedenza (priorità) di un operatore specifica quanto "strettamente" lega due espressioni insieme. Ad esempio, nell'espressione 1 + 5 * 3, la risposta è 16 e non 18 perché l'operatore di moltiplicazione ("*") ha una precedenza maggiore rispetto all'operatore di addizione ("+").

Mischiandoli insieme in un'unica operazione, potresti ottenere risultati imprevisti in alcuni casi, ti consiglio di usare sempre &&, ma è una tua scelta.

D'altra parte "&" è un'operazione AND bit a bit . È utilizzato per la valutazione e la manipolazione di bit specifici all'interno del valore intero.

Esempio se lo fai (14 e 7) il risultato sarebbe 6.

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

Che versione stai usando?

Se gli standard di codifica per la particolare base di codice per cui sto scrivendo il codice specifica quale operatore debba essere usato, lo userò sicuramente . In caso contrario, e il codice indica quale dovrebbe essere usato (non spesso, può essere facilmente risolto) allora lo userò. Altrimenti, probabilmente && .

"E" sono più leggibili di "&&"?

È più leggibile per te . La risposta è sì e no a seconda di molti fattori tra cui il codice attorno all'operatore e in effetti la persona che lo legge!

|| c'è ~ differenza?

Sì. Vedere operatori logici per ||e operatori bit a bit per ~.

Immagino sia una questione di gusti, anche se (erroneamente) mescolarli potrebbe causare comportamenti indesiderati:

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

true and false || false; // returns true

Quindi, usando && e || è più sicuro perché hanno la massima precedenza. Per quanto riguarda la leggibilità, direi che questi operatori sono abbastanza universali.

AGGIORNAMENTO : Circa i commenti che affermano che entrambe le operazioni restituiscono false ... beh, in effetti il ​​codice sopra non restituisce nulla, mi dispiace per l'ambiguità. Per chiarire: il comportamento nel secondo caso dipende da come viene utilizzato il risultato dell'operazione. Osserva come entra in gioco la precedenza degli operatori:

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

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

Il motivo $a === trueè perché l'operatore di assegnazione ha la precedenza su qualsiasi operatore logico, come già spiegato molto bene in altre risposte.

Ecco un piccolo esempio contatore:

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

produzione:

bool(false)

Direi che questo tipo di refuso ha molte più probabilità di causare problemi insidiosi (più o meno allo stesso modo di =vs ==) ed è molto meno probabile che si notino adn/ roerrori di battitura che segnaleranno come errori di sintassi. Inoltre trovo e / o è molto più facile da leggere. FWIW, la maggior parte dei framework PHP che esprimono una preferenza (la maggior parte non lo specifica) specifica e / o. Inoltre non mi sono mai imbattuto in un caso reale e non inventato in cui avrebbe avuto importanza.

Un altro bell'esempio usando ifistruzioni senza =operazioni di assegnazione.

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

e

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

perché ANDha una precedenza inferiore e quindi|| una precedenza più alta.

Questi sono diversi nei casi di true, false, falsee true, true, false. Vedi https://ideone.com/lsqovs per un esempio elaborato.