'AND' vs '&&' como operador

Eu tenho uma base de código onde os desenvolvedores decidiram usar ANDe em ORvez de &&e ||.

Eu sei que há uma diferença na precedência dos operadores ( &&vai antes and), mas com a estrutura fornecida ( PrestaShop para ser preciso) claramente não é uma razão.

Qual versão você está usando? É andmais legível do que &&? Ou não há diferença?

Se você usar ANDe OR, eventualmente, será enganado por algo assim:

$this_one = true;
$that = false;

$truthiness = $this_one and $that;

Quer adivinhar o que $truthinessé igual?

Se você disse false... bzzzt, desculpe, errado!

$truthinessacima tem o valor true. Por quê? =tem uma precedência mais alta que and. A adição de parênteses para mostrar a ordem implícita torna isso mais claro:

($truthiness = $this_one) and $that

Se você usasse no &&lugar do andprimeiro exemplo de código, ele funcionaria como esperado e estará false.

Conforme discutido nos comentários abaixo, isso também funciona para obter o valor correto, pois os parênteses têm maior precedência do que =:

$truthiness = ($this_one and $that)

Dependendo de como está sendo usado, pode ser necessário e até útil. 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;

Mas na maioria dos casos, parece mais um gosto do desenvolvedor, como todas as ocorrências disso que eu já vi no framework CodeIgniter, como o @Sarfraz mencionou.

Por questões de segurança, sempre coloco parênteses em minhas comparações e as espaço. Dessa forma, não preciso confiar na precedência do operador:

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

A precedência difere entre && e e (&& tem maior precedência que e), algo que causa confusão quando combinado com um operador ternário. Por exemplo,

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

retornará uma string enquanto

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

retornará um booleano .

Como andtem precedência menor do que =você pode usá-lo na atribuição de condições:

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

Deixe-me explicar a diferença entre "e" - "&&" - "&".

"&&" e "e" são operações AND lógicas e fazem a mesma coisa, mas a precedência do operador é diferente.

A precedência (prioridade) de um operador especifica quão "firmemente" ele liga duas expressões. Por exemplo, na expressão 1 + 5 * 3, a resposta é 16 e não 18 porque o operador de multiplicação ("*") tem uma precedência mais alta que o operador de adição ("+").

Misturá-los juntos em uma única operação, pode dar resultados inesperados em alguns casos, eu recomendo sempre usar &&, mas essa é a sua escolha.

Por outro lado, "&" é uma operação AND bit a bit . É usado para a avaliação e manipulação de bits específicos dentro do valor inteiro.

Exemplo: se você fizer (14 e 7), o resultado será 6.

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

Qual versão você está usando?

Se os padrões de codificação para a base de código específica para a qual estou escrevendo o código especificar qual operador deve ser usado, eu definitivamente o utilizarei. Caso contrário, e o código determina qual deve ser usado (não frequentemente, pode ser facilmente contornado), então usarei isso. Caso contrário, provavelmente && .

É 'e' mais legível que '&&'?

É mais legível para você . A resposta é sim e não, dependendo de muitos fatores, incluindo o código em torno do operador e, de fato, a pessoa que o lê!

|| há ~ diferença?

Sim. Consulte operadores lógicos para ||e operadores bit a bit para ~.

Eu acho que é uma questão de gosto, embora (erroneamente) misturá-las possa causar alguns comportamentos indesejados:

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

true and false || false; // returns true

Portanto, usando && e || é mais seguro, pois eles têm a maior precedência. No que diz respeito à legibilidade, eu diria que esses operadores são universais o suficiente.

ATUALIZAÇÃO : Sobre os comentários dizendo que ambas as operações retornam falsas ... bem, na verdade o código acima não retorna nada, desculpe-me pela ambiguidade. Para esclarecer: o comportamento no segundo caso depende de como o resultado da operação é usado. Observe como a precedência dos operadores entra em jogo aqui:

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

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

O motivo $a === trueé que o operador de atribuição tem precedência sobre qualquer operador lógico, como já foi muito bem explicado em outras respostas.

Aqui está um pequeno exemplo de contador:

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

resultado:

bool(false)

Eu diria que esse tipo de erro de digitação tem muito mais probabilidade de causar problemas insidiosos (da mesma maneira que =vs ==) e tem muito menos probabilidade de ser notado do que adn/ rotypo, que sinalizará como erros de sintaxe. Também acho e / ou é muito mais fácil de ler. FWIW, a maioria das estruturas PHP que expressam uma preferência (a maioria não) especifica e / ou. Eu também nunca me deparei com um caso real, não artificial, em que isso teria importância.

Outro bom exemplo usando ifinstruções sem =operações de atribuição.

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

porque ANDtem uma precedência mais baixa e, portanto, ||uma precedência mais alta.

Estes são diferentes nos casos de true, false, falsee true, true, false. Veja https://ideone.com/lsqovs para um exemplo elaborado.