Tengo una base de código donde los desarrolladores decidieron usar AND
y en OR
lugar de &&
y ||
.
Sé que hay una diferencia en la precedencia de los operadores ( &&
va antes and
), pero con el marco dado ( PrestaShop para ser precisos) claramente no es una razón.
¿Qué versión está utilizando? ¿Es and
más legible que &&
? ¿O no hay diferencia?
~
es el operador NOT en cuanto a bits y no el lógico. ;-)Respuestas:
Si usas
AND
yOR
, eventualmente te tropezarás con algo como esto:¿Quieres adivinar lo que
$truthiness
es igual?Si dijiste
false
... bzzzt, lo siento, ¡mal!$truthiness
arriba tiene el valortrue
. ¿Por qué?=
tiene mayor precedencia queand
. La adición de paréntesis para mostrar el orden implícito aclara esto:Si usó en
&&
lugar deland
primer ejemplo de código, funcionaría como se esperaba y seríafalse
.Como se discute en los comentarios a continuación, esto también funciona para obtener el valor correcto, ya que los paréntesis tienen mayor prioridad que
=
:fuente
and
or
una vez por todas. Vi demasiadas personas pensando que son exactamente lo mismo y las respuestas aquí son más testimonios.$foo and bar()
, que son atajos agradables para sentencias if. Si el comportamiento inesperado (por mala documentación, o no leerlo) fuera una razón para no usar algo de lo que no estaríamos hablando en absoluto usando PHP.Dependiendo de cómo se use, puede ser necesario e incluso útil. http://php.net/manual/en/language.operators.logical.php
Pero en la mayoría de los casos parece más un gusto de desarrollador, como cada vez que ocurre esto que he visto en el marco de CodeIgniter como @Sarfraz ha mencionado.
fuente
if ($f = false or true) $f = true;
: el resultado sería que$f
se convierte en verdadero al final, porque la expresión se evalúa como verdadera en general.$f
se le asigna falso, pero la condición se evalúa como verdadera, por lo que$f
se sobrescribe. Si la condición se evalúa como falsa,$f
nunca se sobrescribirá de ninguna manera.and
más&&
, dondeand
funciona como se espera en sólo algunas situaciones y&&
funciona como se espera en toda situacionesPor seguridad, siempre hago paréntesis entre mis comparaciones y las espacio. De esa manera, no tengo que depender de la precedencia del operador:
fuente
La precedencia difiere entre && y y (&& tiene mayor precedencia que y), algo que causa confusión cuando se combina con un operador ternario. Por ejemplo,
devolverá una cadena mientras que
devolverá un booleano .
fuente
Dado que
and
tiene una precedencia inferior a la=
que puede usar en la asignación de condiciones:fuente
"&&" y "y" ambos son operaciones lógicas AND y hacen lo mismo, pero la precedencia del operador es diferente.
La precedencia (prioridad) de un operador especifica cuán "estrechamente" une dos expresiones. Por ejemplo, en la expresión 1 + 5 * 3, la respuesta es 16 y no 18 porque el operador de multiplicación ("*") tiene mayor prioridad que el operador de suma ("+").
Si los mezcla en una sola operación, podría obtener resultados inesperados en algunos casos , siempre recomiendo usar &&, pero esa es su elección.
Por otro lado, "&" es una operación AND a nivel de bits . Se utiliza para la evaluación y manipulación de bits específicos dentro del valor entero.
Ejemplo si lo haces (14 y 7) el resultado sería 6.
fuente
Si los estándares de codificación para la base de código particular para la que escribo el código especifican qué operador debe usarse, definitivamente lo usaré. Si no es así, y el código dicta cuál debe usarse (no es frecuente, se puede solucionar fácilmente), entonces lo usaré. De lo contrario, probablemente
&&
.¿Es más legible para usted ? ¡La respuesta es sí y no dependiendo de muchos factores, incluido el código que rodea al operador y, de hecho, la persona que lo lee!
Si. Ver operadores lógicos para
||
y operadores bit a bit para~
.fuente
Supongo que es cuestión de gustos, aunque (por error) mezclarlos podría causar algunos comportamientos no deseados:
Por lo tanto, usando && y || es más seguro porque tienen la más alta prioridad. En cuanto a la legibilidad, diría que estos operadores son lo suficientemente universales.
ACTUALIZACIÓN : Sobre los comentarios que dicen que ambas operaciones devuelven falso ... bueno, de hecho el código anterior no devuelve nada, lamento la ambigüedad. Para aclarar: el comportamiento en el segundo caso depende de cómo se use el resultado de la operación. Observe cómo la precedencia de los operadores entra en juego aquí:
La razón
$a === true
es porque el operador de asignación tiene prioridad sobre cualquier operador lógico, como ya se explicó muy bien en otras respuestas.fuente
Aquí hay un pequeño ejemplo de contador:
salida:
Diría que este tipo de error tipográfico es mucho más probable que cause problemas insidiosos (de la misma manera que
=
vs==
) y es mucho menos probable que se note queadn
/ro
typos, que marcará como errores de sintaxis. También encuentro y / o es mucho más fácil de leer. FWIW, la mayoría de los marcos PHP que expresan una preferencia (la mayoría no) especifican y / o. Tampoco me he encontrado con un caso real y no inventado en el que hubiera importado.fuente
Otro buen ejemplo usando
if
declaraciones sin=
operaciones de asignación.y
porque
AND
tiene una precedencia más baja y, por lo tanto,||
una precedencia más alta.Estos son diferentes en los casos de
true, false, false
ytrue, true, false
. Consulte https://ideone.com/lsqovs para obtener un ejemplo detallado.fuente