AND" vs. "&&" als Operator

Question

Ich habe eine Codebasis, bei der die Entwickler beschlossen haben, die AND y OR 代わりに && y || .

Ich weiß, dass es einen Unterschied in der Rangfolge der Operatoren gibt ( && geht vor and ), sondern mit dem vorgegebenen Rahmen ( PrestaShop um genau zu sein) ist es eindeutig kein Grund.

Welche Version verwenden Sie? Ist and besser lesbar als && ? Oder gibt es keinen Unterschied?

Answer 1

Lassen Sie mich den Unterschied zwischen "und" - "&&" - "&" erklären.

"&&" und "und" sind beide logische UND-Verknüpfungen und sie tun dasselbe, aber die Priorität der Operatoren ist unterschiedlich.

Die Rangfolge (Priorität) eines Operators gibt an, wie "eng" er zwei Ausdrücke miteinander verbindet. Bei dem Ausdruck 1 + 5 * 3 lautet die Antwort beispielsweise 16 und nicht 18, weil der Multiplikationsoperator ("*") einen höheren Vorrang hat als der Additionsoperator ("+").

Werden sie in einem einzigen Arbeitsgang gemischt, kann dies in einigen Fällen zu unerwarteten Ergebnissen führen Ich empfehle, immer && zu verwenden, aber das ist Ihre Entscheidung.

---

Andererseits ist "&" ein bitweise UND-Verknüpfung . Er wird für die Auswertung und Manipulation bestimmter Bits innerhalb eines Integer-Wertes verwendet.

Wenn Sie zum Beispiel (14 & 7) machen, wäre das Ergebnis 6.

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

Answer 2

Ein weiteres schönes Beispiel mit if Aussagen ohne = Zuweisungsvorgänge.

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

denn AND hat einen niedrigeren Vorrang und somit || einen höheren Stellenwert.

Diese sind unterschiedlich in den Fällen true, false, false y true, true, false . Siehe https://ideone.com/lsqovs für en ausführliches Beispiel.

Answer 3

Welche Version verwenden Sie?

Wenn die Codierungsstandards für die jeweilige Codebasis, für die ich Code schreibe, vorschreiben, welcher Operator verwendet werden soll, werde ich definitiv das verwenden. Wenn nicht, und der Code diktiert die verwendet werden sollte (nicht oft, kann leicht umgangen werden), dann werde ich das verwenden. Ansonsten, wahrscheinlich && .

Ist "und" besser lesbar als "&&"?

Ist sie besser lesbar für Sie . Die Antwort lautet ja und nein Das hängt von vielen Faktoren ab, unter anderem vom Code des Betreibers und der Person, die ihn liest!

|| Gibt es einen Unterschied?

Ja, siehe logische Operatoren para || y bitweise Operatoren para ~ .

Answer 4

Ich denke, es ist eine Frage des Geschmacks, auch wenn die Verwechslung (fälschlicherweise) zu unerwünschten Verhaltensweisen führen kann:

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

true and false || false; // returns true

Daher ist es sicherer, && und || zu verwenden, da sie den höchsten Vorrang haben. Was die Lesbarkeit angeht, so sind diese Operatoren universell genug.

UPDATE : Zu den Kommentaren, die besagen, dass beide Operationen false zurückgeben ... nun, in der Tat gibt der obige Code nichts zurück, es tut mir leid für die Zweideutigkeit. Zur Klarstellung: Das Verhalten im zweiten Fall hängt davon ab, wie das Ergebnis der Operation verwendet wird. Beobachten Sie, wie die Rangfolge der Operatoren hier ins Spiel kommt:

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

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

Der Grund dafür $a === true liegt daran, dass der Zuweisungsoperator Vorrang vor allen logischen Operatoren hat, wie bereits in anderen Antworten sehr gut erklärt wurde.

Answer 5

Hier ist ein kleines Gegenbeispiel:

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

Ausgabe:

bool(false)

Ich würde sagen, dass diese Art von Tippfehlern weitaus wahrscheinlicher schleichende Probleme verursacht (in ähnlicher Weise wie = gegen == ) und wird weitaus seltener wahrgenommen als adn / ro Tippfehler, die als Syntaxfehler gekennzeichnet werden. Ich finde auch, dass und/oder viel einfacher zu lesen ist. FWIW, die meisten PHP-Frameworks, die eine Präferenz ausdrücken (die meisten tun es nicht), spezifizieren und/oder. Mir ist auch noch nie ein echter, nicht konstruierter Fall begegnet, in dem es eine Rolle gespielt hätte.