'AND' vs '&&' as operator
I have a codebase where developers decided to use AND and OR instead of && and ||.
I know that there is a difference in operators' precedence (&& goes before and), but with the given framework (PrestaShop to be precise) it is clearly not a reason.
Which version are you using? Is and more readable than &&? Or is there no difference?
php coding-style operators
|
show 3 more comments
I have a codebase where developers decided to use AND and OR instead of && and ||.
I know that there is a difference in operators' precedence (&& goes before and), but with the given framework (PrestaShop to be precise) it is clearly not a reason.
Which version are you using? Is and more readable than &&? Or is there no difference?
php coding-style operators
1
Note that~is the bit-wise NOT operator and not the logical. ;-)
– Gumbo
May 10 '10 at 14:26
2
Yes, i know. Bad habits :) . It is a little bit strange that in PHP there are 'and', 'or' and 'xor', but there is no 'not', isn't it?
– ts.
May 12 '10 at 10:30
1
@ts: the correct answer here is the one provided by R. Bemrose stackoverflow.com/questions/2803321/and-vs-as-operator/…
– Marco Demaio
May 24 '11 at 15:45
4
! is the logical not operator
– Razor Storm
May 30 '11 at 8:15
2
@chiliNUT quite right. At the time it must have made sense. Looks like the lurking incorrect answer has been punished at this point :)
– doublejosh
Mar 28 '14 at 19:34
|
show 3 more comments
I have a codebase where developers decided to use AND and OR instead of && and ||.
I know that there is a difference in operators' precedence (&& goes before and), but with the given framework (PrestaShop to be precise) it is clearly not a reason.
Which version are you using? Is and more readable than &&? Or is there no difference?
php coding-style operators
I have a codebase where developers decided to use AND and OR instead of && and ||.
I know that there is a difference in operators' precedence (&& goes before and), but with the given framework (PrestaShop to be precise) it is clearly not a reason.
Which version are you using? Is and more readable than &&? Or is there no difference?
php coding-style operators
php coding-style operators
edited Dec 6 '15 at 10:41
Peter Mortensen
13.7k1986111
13.7k1986111
asked May 10 '10 at 14:20
ts.ts.
5,60473761
5,60473761
1
Note that~is the bit-wise NOT operator and not the logical. ;-)
– Gumbo
May 10 '10 at 14:26
2
Yes, i know. Bad habits :) . It is a little bit strange that in PHP there are 'and', 'or' and 'xor', but there is no 'not', isn't it?
– ts.
May 12 '10 at 10:30
1
@ts: the correct answer here is the one provided by R. Bemrose stackoverflow.com/questions/2803321/and-vs-as-operator/…
– Marco Demaio
May 24 '11 at 15:45
4
! is the logical not operator
– Razor Storm
May 30 '11 at 8:15
2
@chiliNUT quite right. At the time it must have made sense. Looks like the lurking incorrect answer has been punished at this point :)
– doublejosh
Mar 28 '14 at 19:34
|
show 3 more comments
1
Note that~is the bit-wise NOT operator and not the logical. ;-)
– Gumbo
May 10 '10 at 14:26
2
Yes, i know. Bad habits :) . It is a little bit strange that in PHP there are 'and', 'or' and 'xor', but there is no 'not', isn't it?
– ts.
May 12 '10 at 10:30
1
@ts: the correct answer here is the one provided by R. Bemrose stackoverflow.com/questions/2803321/and-vs-as-operator/…
– Marco Demaio
May 24 '11 at 15:45
4
! is the logical not operator
– Razor Storm
May 30 '11 at 8:15
2
@chiliNUT quite right. At the time it must have made sense. Looks like the lurking incorrect answer has been punished at this point :)
– doublejosh
Mar 28 '14 at 19:34
1
1
Note that
~ is the bit-wise NOT operator and not the logical. ;-)– Gumbo
May 10 '10 at 14:26
Note that
~ is the bit-wise NOT operator and not the logical. ;-)– Gumbo
May 10 '10 at 14:26
2
2
Yes, i know. Bad habits :) . It is a little bit strange that in PHP there are 'and', 'or' and 'xor', but there is no 'not', isn't it?
– ts.
May 12 '10 at 10:30
Yes, i know. Bad habits :) . It is a little bit strange that in PHP there are 'and', 'or' and 'xor', but there is no 'not', isn't it?
– ts.
May 12 '10 at 10:30
1
1
@ts: the correct answer here is the one provided by R. Bemrose stackoverflow.com/questions/2803321/and-vs-as-operator/…
– Marco Demaio
May 24 '11 at 15:45
@ts: the correct answer here is the one provided by R. Bemrose stackoverflow.com/questions/2803321/and-vs-as-operator/…
– Marco Demaio
May 24 '11 at 15:45
4
4
! is the logical not operator
– Razor Storm
May 30 '11 at 8:15
! is the logical not operator
– Razor Storm
May 30 '11 at 8:15
2
2
@chiliNUT quite right. At the time it must have made sense. Looks like the lurking incorrect answer has been punished at this point :)
– doublejosh
Mar 28 '14 at 19:34
@chiliNUT quite right. At the time it must have made sense. Looks like the lurking incorrect answer has been punished at this point :)
– doublejosh
Mar 28 '14 at 19:34
|
show 3 more comments
11 Answers
11
active
oldest
votes
If you use AND and OR, you'll eventually get tripped up by something like this:
$this_one = true;
$that = false;
$truthiness = $this_one and $that;
Want to guess what $truthiness equals?
If you said false... bzzzt, sorry, wrong!
$truthiness above has the value true. Why? = has a higher precedence than and. The addition of parentheses to show the implicit order makes this clearer:
($truthiness = $this_one) and $that
If you used && instead of and in the first code example, it would work as expected and be false.
As discussed in the comments below, this also works to get the correct value, as parentheses have higher precedence than =:
$truthiness = ($this_one and $that)
118
+1: this should be made loud and clear in PHP documentation, or PHP should change and give same precedence to these operators or DEPRECATEandoronce for all. I saw too many people thinking they are exactly the same thing and the answers here are more testimonials.
– Marco Demaio
May 24 '11 at 15:44
10
Actually, other languages (for example, Perl and Ruby) also have these variants with the same precedence distinction so it wouldn't be sensible to deviate from this standard (however puzzling it might be for beginners) by making precedence equal in PHP. Not to mention the backward compatibility of tons of PHP applications.
– Mladen Jablanović
Jan 25 '12 at 8:27
22
People's inability to read the documentation for a language does not make the language's decisions wrong. As Mladen notes, Perl and Ruby also use these extra operators, and with the same precedences. It allows for constructs such as$foo and bar(), which are nice shortcuts for if statements. If unexpected behaviour (from bad documentation, or not reading it) were a reason not to use something we wouldn't be talking about using PHP at all.
– Altreus
Aug 30 '12 at 11:49
2
I spent 3 minutes to find wrong line: $this = true, :( and what about $truthiness = ($this and $that); it's look better for me :)
– Dmitriy Kozmenko
May 6 '13 at 15:52
6
I agree with Dmitriy - wrapping the boolean evaluation in parentheses helps to clarify the intent of the code. I think the operator and it's function as they now exist are valuable and consistent with other languages, it's the job of the programmer to understand the language.
– Jon z
May 12 '13 at 13:59
|
show 12 more comments
Depending on how it's being used, it might be necessary and even handy.
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;
But in most cases it seems like more of a developer taste thing, like every occurrence of this that I've seen in CodeIgniter framework like @Sarfraz has mentioned.
2
It's worth noting that the "true" isn't ignored if that expression is part of a larger statement. Consider the caseif ($f = false or true) $f = true;- the result would be that$fdoes become true in the end, because the expression evaluates as true overall.
– Chris Browne
Mar 15 '12 at 22:04
1
no, you simply overwrote the variable later. the expression still evaluated to false, then you overwrote it with true in the next line.
– r3wt
May 13 '14 at 21:50
2
Actually, he was right. First,$fgets assigned false - but the condition evaluates to true, so then$fis overwritten. If the condition evaluated to false,$fwould never been overwritten either way.
– ahouse101
Jun 29 '14 at 23:58
It's ridiculous to suggest the developers should follow their own taste. Forget the nightmare of another developer trying to maintain the same code, the developer who wrote the code itself would be making semantic mistakes in any code written because s/he preferredandover&&, whereandworks as expected in only some situations and&&works as expected in all situations.
– ADTC
Sep 7 '18 at 19:49
add a comment |
For safety, I always parenthesise my comparisons and space them out. That way, I don't have to rely on operator precedence:
if(
((i==0) && (b==2))
||
((c==3) && !(f==5))
)
4
Very safe. Good.
– MarcoZen
Jul 5 '13 at 16:56
26
Personally I think adding extra unnecessary parentheses makes it more confusing to read than having just what you need. For example, I think this is much easier to read: if (($i == 0 && $b == 2) || ($c == 3 && $f != 5))
– rooby
May 11 '14 at 7:40
i agree @rooby that is much easier for me to read as well.
– r3wt
May 13 '14 at 21:52
3
I think this is the prettiest piece of code I've looked at all day. Good job.
– rm-vanda
Dec 30 '14 at 22:58
As PHP is an interpreted language it will run fast if you don't use unnecessary whitespaces or new lines on your code. If you do the same on a compiled language it only will take more time to compile but it will not take effect on runtime. I don't mean doing it once will mark a difference but on an entire application using php + javascript both wrote like the example... load times will be larger for sure. Explanation: Whitespaces and new lines are ignored, but to ignore them, they have to be checked. This happens at runtime on interpreted langs and when compiling on a compiled ones.
– JoelBonetR
Apr 6 '18 at 19:12
|
show 3 more comments
Since and has lower precedence than = you can use it in condition assignment:
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
add a comment |
Precedence differs between && and and (&& has higher precedence than and), something that causes confusion when combined with a ternary operator. For instance,
$predA && $predB ? "foo" : "bar"
will return a string whereas
$predA and $predB ? "foo" : "bar"
will return a boolean.
add a comment |
which version are you using?
If the coding standards for the particular codebase I am writing code for specifies which operator should be used, I'll definitely use that. If not, and the code dictates which should be used (not often, can be easily worked around) then I'll use that. Otherwise, probably &&.
Is 'and' more readable than '&&'?
Is it more readable to you. The answer is yes and no depending on many factors including the code around the operator and indeed the person reading it!
|| there is ~ difference?
Yes. See logical operators for || and bitwise operators for ~.
add a comment |
Let me explain the difference between “and” - “&&” - "&".
"&&" and "and" both are logical AND operations and they do the same thing, but the operator precedence is different.
The precedence (priority) of an operator specifies how "tightly" it binds two expressions together. For example, in the expression 1 + 5 * 3, the answer is 16 and not 18 because the multiplication ("*") operator has a higher precedence than the addition ("+") operator.
Mixing them together in single operation, could give you unexpected results in some cases
I recommend always using &&, but that's your choice.
On the other hand "&" is a bitwise AND operation. It's used for the evaluation and manipulation of specific bits within the integer value.
Example if you do (14 & 7) the result would be 6.
7 = 0111
14 = 1110
------------
= 0110 == 6
add a comment |
I guess it's a matter of taste, although (mistakenly) mixing them up might cause some undesired behaviors:
true && false || false; // returns false
true and false || false; // returns true
Hence, using && and || is safer for they have the highest precedence. In what regards to readability, I'd say these operators are universal enough.
UPDATE: About the comments saying that both operations return false ... well, in fact the code above does not return anything, I'm sorry for the ambiguity. To clarify: the behavior in the second case depends on how the result of the operation is used. Observe how the precedence of operators comes into play here:
var_dump(true and false || false); // bool(false)
$a = true and false || false; var_dump($a); // bool(true)
The reason why $a === true is because the assignment operator has precedence over any logical operator, as already very well explained in other answers.
15
This isn't true, they all return false.
– Jay
Feb 22 '13 at 0:26
1
-1 I think @Jay is right.
– giannis christofakis
Jul 9 '13 at 9:50
add a comment |
Here's a little counter example:
$a = true;
$b = true;
$c = $a & $b;
var_dump(true === $c);
output:
bool(false)
I'd say this kind of typo is far more likely to cause insidious problems (in much the same way as = vs ==) and is far less likely to be noticed than adn/ro typos which will flag as syntax errors. I also find and/or is much easier to read. FWIW, most PHP frameworks that express a preference (most don't) specify and/or. I've also never run into a real, non-contrived case where it would have mattered.
add a comment |
Depending on the language that you are using, generally it is better practice to use
&&and||rather thanandandor, except in languages like Python, whereandandorare used instead and&&and||do not exist.
add a comment |
Another nice example using if statements without = assignment operations.
if (true || true && false); // is the same as:
if (true || (true && false)); // TRUE
and
if (true || true AND false); // is the same as:
if ((true || true) && false); // FALSE
because AND has a lower precedence and thus || a higher precedence.
These are different in the cases of true, false, false and true, true, false.
See https://ideone.com/lsqovs for en elaborate example.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f2803321%2fand-vs-as-operator%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
11 Answers
11
active
oldest
votes
11 Answers
11
active
oldest
votes
active
oldest
votes
active
oldest
votes
If you use AND and OR, you'll eventually get tripped up by something like this:
$this_one = true;
$that = false;
$truthiness = $this_one and $that;
Want to guess what $truthiness equals?
If you said false... bzzzt, sorry, wrong!
$truthiness above has the value true. Why? = has a higher precedence than and. The addition of parentheses to show the implicit order makes this clearer:
($truthiness = $this_one) and $that
If you used && instead of and in the first code example, it would work as expected and be false.
As discussed in the comments below, this also works to get the correct value, as parentheses have higher precedence than =:
$truthiness = ($this_one and $that)
118
+1: this should be made loud and clear in PHP documentation, or PHP should change and give same precedence to these operators or DEPRECATEandoronce for all. I saw too many people thinking they are exactly the same thing and the answers here are more testimonials.
– Marco Demaio
May 24 '11 at 15:44
10
Actually, other languages (for example, Perl and Ruby) also have these variants with the same precedence distinction so it wouldn't be sensible to deviate from this standard (however puzzling it might be for beginners) by making precedence equal in PHP. Not to mention the backward compatibility of tons of PHP applications.
– Mladen Jablanović
Jan 25 '12 at 8:27
22
People's inability to read the documentation for a language does not make the language's decisions wrong. As Mladen notes, Perl and Ruby also use these extra operators, and with the same precedences. It allows for constructs such as$foo and bar(), which are nice shortcuts for if statements. If unexpected behaviour (from bad documentation, or not reading it) were a reason not to use something we wouldn't be talking about using PHP at all.
– Altreus
Aug 30 '12 at 11:49
2
I spent 3 minutes to find wrong line: $this = true, :( and what about $truthiness = ($this and $that); it's look better for me :)
– Dmitriy Kozmenko
May 6 '13 at 15:52
6
I agree with Dmitriy - wrapping the boolean evaluation in parentheses helps to clarify the intent of the code. I think the operator and it's function as they now exist are valuable and consistent with other languages, it's the job of the programmer to understand the language.
– Jon z
May 12 '13 at 13:59
|
show 12 more comments
If you use AND and OR, you'll eventually get tripped up by something like this:
$this_one = true;
$that = false;
$truthiness = $this_one and $that;
Want to guess what $truthiness equals?
If you said false... bzzzt, sorry, wrong!
$truthiness above has the value true. Why? = has a higher precedence than and. The addition of parentheses to show the implicit order makes this clearer:
($truthiness = $this_one) and $that
If you used && instead of and in the first code example, it would work as expected and be false.
As discussed in the comments below, this also works to get the correct value, as parentheses have higher precedence than =:
$truthiness = ($this_one and $that)
118
+1: this should be made loud and clear in PHP documentation, or PHP should change and give same precedence to these operators or DEPRECATEandoronce for all. I saw too many people thinking they are exactly the same thing and the answers here are more testimonials.
– Marco Demaio
May 24 '11 at 15:44
10
Actually, other languages (for example, Perl and Ruby) also have these variants with the same precedence distinction so it wouldn't be sensible to deviate from this standard (however puzzling it might be for beginners) by making precedence equal in PHP. Not to mention the backward compatibility of tons of PHP applications.
– Mladen Jablanović
Jan 25 '12 at 8:27
22
People's inability to read the documentation for a language does not make the language's decisions wrong. As Mladen notes, Perl and Ruby also use these extra operators, and with the same precedences. It allows for constructs such as$foo and bar(), which are nice shortcuts for if statements. If unexpected behaviour (from bad documentation, or not reading it) were a reason not to use something we wouldn't be talking about using PHP at all.
– Altreus
Aug 30 '12 at 11:49
2
I spent 3 minutes to find wrong line: $this = true, :( and what about $truthiness = ($this and $that); it's look better for me :)
– Dmitriy Kozmenko
May 6 '13 at 15:52
6
I agree with Dmitriy - wrapping the boolean evaluation in parentheses helps to clarify the intent of the code. I think the operator and it's function as they now exist are valuable and consistent with other languages, it's the job of the programmer to understand the language.
– Jon z
May 12 '13 at 13:59
|
show 12 more comments
If you use AND and OR, you'll eventually get tripped up by something like this:
$this_one = true;
$that = false;
$truthiness = $this_one and $that;
Want to guess what $truthiness equals?
If you said false... bzzzt, sorry, wrong!
$truthiness above has the value true. Why? = has a higher precedence than and. The addition of parentheses to show the implicit order makes this clearer:
($truthiness = $this_one) and $that
If you used && instead of and in the first code example, it would work as expected and be false.
As discussed in the comments below, this also works to get the correct value, as parentheses have higher precedence than =:
$truthiness = ($this_one and $that)
If you use AND and OR, you'll eventually get tripped up by something like this:
$this_one = true;
$that = false;
$truthiness = $this_one and $that;
Want to guess what $truthiness equals?
If you said false... bzzzt, sorry, wrong!
$truthiness above has the value true. Why? = has a higher precedence than and. The addition of parentheses to show the implicit order makes this clearer:
($truthiness = $this_one) and $that
If you used && instead of and in the first code example, it would work as expected and be false.
As discussed in the comments below, this also works to get the correct value, as parentheses have higher precedence than =:
$truthiness = ($this_one and $that)
edited Jun 15 '18 at 9:08
jedema
5,00753461
5,00753461
answered May 10 '10 at 14:48
PowerlordPowerlord
74k14112160
74k14112160
118
+1: this should be made loud and clear in PHP documentation, or PHP should change and give same precedence to these operators or DEPRECATEandoronce for all. I saw too many people thinking they are exactly the same thing and the answers here are more testimonials.
– Marco Demaio
May 24 '11 at 15:44
10
Actually, other languages (for example, Perl and Ruby) also have these variants with the same precedence distinction so it wouldn't be sensible to deviate from this standard (however puzzling it might be for beginners) by making precedence equal in PHP. Not to mention the backward compatibility of tons of PHP applications.
– Mladen Jablanović
Jan 25 '12 at 8:27
22
People's inability to read the documentation for a language does not make the language's decisions wrong. As Mladen notes, Perl and Ruby also use these extra operators, and with the same precedences. It allows for constructs such as$foo and bar(), which are nice shortcuts for if statements. If unexpected behaviour (from bad documentation, or not reading it) were a reason not to use something we wouldn't be talking about using PHP at all.
– Altreus
Aug 30 '12 at 11:49
2
I spent 3 minutes to find wrong line: $this = true, :( and what about $truthiness = ($this and $that); it's look better for me :)
– Dmitriy Kozmenko
May 6 '13 at 15:52
6
I agree with Dmitriy - wrapping the boolean evaluation in parentheses helps to clarify the intent of the code. I think the operator and it's function as they now exist are valuable and consistent with other languages, it's the job of the programmer to understand the language.
– Jon z
May 12 '13 at 13:59
|
show 12 more comments
118
+1: this should be made loud and clear in PHP documentation, or PHP should change and give same precedence to these operators or DEPRECATEandoronce for all. I saw too many people thinking they are exactly the same thing and the answers here are more testimonials.
– Marco Demaio
May 24 '11 at 15:44
10
Actually, other languages (for example, Perl and Ruby) also have these variants with the same precedence distinction so it wouldn't be sensible to deviate from this standard (however puzzling it might be for beginners) by making precedence equal in PHP. Not to mention the backward compatibility of tons of PHP applications.
– Mladen Jablanović
Jan 25 '12 at 8:27
22
People's inability to read the documentation for a language does not make the language's decisions wrong. As Mladen notes, Perl and Ruby also use these extra operators, and with the same precedences. It allows for constructs such as$foo and bar(), which are nice shortcuts for if statements. If unexpected behaviour (from bad documentation, or not reading it) were a reason not to use something we wouldn't be talking about using PHP at all.
– Altreus
Aug 30 '12 at 11:49
2
I spent 3 minutes to find wrong line: $this = true, :( and what about $truthiness = ($this and $that); it's look better for me :)
– Dmitriy Kozmenko
May 6 '13 at 15:52
6
I agree with Dmitriy - wrapping the boolean evaluation in parentheses helps to clarify the intent of the code. I think the operator and it's function as they now exist are valuable and consistent with other languages, it's the job of the programmer to understand the language.
– Jon z
May 12 '13 at 13:59
118
118
+1: this should be made loud and clear in PHP documentation, or PHP should change and give same precedence to these operators or DEPRECATE
and or once for all. I saw too many people thinking they are exactly the same thing and the answers here are more testimonials.– Marco Demaio
May 24 '11 at 15:44
+1: this should be made loud and clear in PHP documentation, or PHP should change and give same precedence to these operators or DEPRECATE
and or once for all. I saw too many people thinking they are exactly the same thing and the answers here are more testimonials.– Marco Demaio
May 24 '11 at 15:44
10
10
Actually, other languages (for example, Perl and Ruby) also have these variants with the same precedence distinction so it wouldn't be sensible to deviate from this standard (however puzzling it might be for beginners) by making precedence equal in PHP. Not to mention the backward compatibility of tons of PHP applications.
– Mladen Jablanović
Jan 25 '12 at 8:27
Actually, other languages (for example, Perl and Ruby) also have these variants with the same precedence distinction so it wouldn't be sensible to deviate from this standard (however puzzling it might be for beginners) by making precedence equal in PHP. Not to mention the backward compatibility of tons of PHP applications.
– Mladen Jablanović
Jan 25 '12 at 8:27
22
22
People's inability to read the documentation for a language does not make the language's decisions wrong. As Mladen notes, Perl and Ruby also use these extra operators, and with the same precedences. It allows for constructs such as
$foo and bar(), which are nice shortcuts for if statements. If unexpected behaviour (from bad documentation, or not reading it) were a reason not to use something we wouldn't be talking about using PHP at all.– Altreus
Aug 30 '12 at 11:49
People's inability to read the documentation for a language does not make the language's decisions wrong. As Mladen notes, Perl and Ruby also use these extra operators, and with the same precedences. It allows for constructs such as
$foo and bar(), which are nice shortcuts for if statements. If unexpected behaviour (from bad documentation, or not reading it) were a reason not to use something we wouldn't be talking about using PHP at all.– Altreus
Aug 30 '12 at 11:49
2
2
I spent 3 minutes to find wrong line: $this = true, :( and what about $truthiness = ($this and $that); it's look better for me :)
– Dmitriy Kozmenko
May 6 '13 at 15:52
I spent 3 minutes to find wrong line: $this = true, :( and what about $truthiness = ($this and $that); it's look better for me :)
– Dmitriy Kozmenko
May 6 '13 at 15:52
6
6
I agree with Dmitriy - wrapping the boolean evaluation in parentheses helps to clarify the intent of the code. I think the operator and it's function as they now exist are valuable and consistent with other languages, it's the job of the programmer to understand the language.
– Jon z
May 12 '13 at 13:59
I agree with Dmitriy - wrapping the boolean evaluation in parentheses helps to clarify the intent of the code. I think the operator and it's function as they now exist are valuable and consistent with other languages, it's the job of the programmer to understand the language.
– Jon z
May 12 '13 at 13:59
|
show 12 more comments
Depending on how it's being used, it might be necessary and even handy.
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;
But in most cases it seems like more of a developer taste thing, like every occurrence of this that I've seen in CodeIgniter framework like @Sarfraz has mentioned.
2
It's worth noting that the "true" isn't ignored if that expression is part of a larger statement. Consider the caseif ($f = false or true) $f = true;- the result would be that$fdoes become true in the end, because the expression evaluates as true overall.
– Chris Browne
Mar 15 '12 at 22:04
1
no, you simply overwrote the variable later. the expression still evaluated to false, then you overwrote it with true in the next line.
– r3wt
May 13 '14 at 21:50
2
Actually, he was right. First,$fgets assigned false - but the condition evaluates to true, so then$fis overwritten. If the condition evaluated to false,$fwould never been overwritten either way.
– ahouse101
Jun 29 '14 at 23:58
It's ridiculous to suggest the developers should follow their own taste. Forget the nightmare of another developer trying to maintain the same code, the developer who wrote the code itself would be making semantic mistakes in any code written because s/he preferredandover&&, whereandworks as expected in only some situations and&&works as expected in all situations.
– ADTC
Sep 7 '18 at 19:49
add a comment |
Depending on how it's being used, it might be necessary and even handy.
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;
But in most cases it seems like more of a developer taste thing, like every occurrence of this that I've seen in CodeIgniter framework like @Sarfraz has mentioned.
2
It's worth noting that the "true" isn't ignored if that expression is part of a larger statement. Consider the caseif ($f = false or true) $f = true;- the result would be that$fdoes become true in the end, because the expression evaluates as true overall.
– Chris Browne
Mar 15 '12 at 22:04
1
no, you simply overwrote the variable later. the expression still evaluated to false, then you overwrote it with true in the next line.
– r3wt
May 13 '14 at 21:50
2
Actually, he was right. First,$fgets assigned false - but the condition evaluates to true, so then$fis overwritten. If the condition evaluated to false,$fwould never been overwritten either way.
– ahouse101
Jun 29 '14 at 23:58
It's ridiculous to suggest the developers should follow their own taste. Forget the nightmare of another developer trying to maintain the same code, the developer who wrote the code itself would be making semantic mistakes in any code written because s/he preferredandover&&, whereandworks as expected in only some situations and&&works as expected in all situations.
– ADTC
Sep 7 '18 at 19:49
add a comment |
Depending on how it's being used, it might be necessary and even handy.
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;
But in most cases it seems like more of a developer taste thing, like every occurrence of this that I've seen in CodeIgniter framework like @Sarfraz has mentioned.
Depending on how it's being used, it might be necessary and even handy.
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;
But in most cases it seems like more of a developer taste thing, like every occurrence of this that I've seen in CodeIgniter framework like @Sarfraz has mentioned.
edited May 24 '11 at 15:37
Marco Demaio
19.7k31110146
19.7k31110146
answered May 10 '10 at 14:27
adamJLevadamJLev
9,219105057
9,219105057
2
It's worth noting that the "true" isn't ignored if that expression is part of a larger statement. Consider the caseif ($f = false or true) $f = true;- the result would be that$fdoes become true in the end, because the expression evaluates as true overall.
– Chris Browne
Mar 15 '12 at 22:04
1
no, you simply overwrote the variable later. the expression still evaluated to false, then you overwrote it with true in the next line.
– r3wt
May 13 '14 at 21:50
2
Actually, he was right. First,$fgets assigned false - but the condition evaluates to true, so then$fis overwritten. If the condition evaluated to false,$fwould never been overwritten either way.
– ahouse101
Jun 29 '14 at 23:58
It's ridiculous to suggest the developers should follow their own taste. Forget the nightmare of another developer trying to maintain the same code, the developer who wrote the code itself would be making semantic mistakes in any code written because s/he preferredandover&&, whereandworks as expected in only some situations and&&works as expected in all situations.
– ADTC
Sep 7 '18 at 19:49
add a comment |
2
It's worth noting that the "true" isn't ignored if that expression is part of a larger statement. Consider the caseif ($f = false or true) $f = true;- the result would be that$fdoes become true in the end, because the expression evaluates as true overall.
– Chris Browne
Mar 15 '12 at 22:04
1
no, you simply overwrote the variable later. the expression still evaluated to false, then you overwrote it with true in the next line.
– r3wt
May 13 '14 at 21:50
2
Actually, he was right. First,$fgets assigned false - but the condition evaluates to true, so then$fis overwritten. If the condition evaluated to false,$fwould never been overwritten either way.
– ahouse101
Jun 29 '14 at 23:58
It's ridiculous to suggest the developers should follow their own taste. Forget the nightmare of another developer trying to maintain the same code, the developer who wrote the code itself would be making semantic mistakes in any code written because s/he preferredandover&&, whereandworks as expected in only some situations and&&works as expected in all situations.
– ADTC
Sep 7 '18 at 19:49
2
2
It's worth noting that the "true" isn't ignored if that expression is part of a larger statement. Consider the case
if ($f = false or true) $f = true; - the result would be that $f does become true in the end, because the expression evaluates as true overall.– Chris Browne
Mar 15 '12 at 22:04
It's worth noting that the "true" isn't ignored if that expression is part of a larger statement. Consider the case
if ($f = false or true) $f = true; - the result would be that $f does become true in the end, because the expression evaluates as true overall.– Chris Browne
Mar 15 '12 at 22:04
1
1
no, you simply overwrote the variable later. the expression still evaluated to false, then you overwrote it with true in the next line.
– r3wt
May 13 '14 at 21:50
no, you simply overwrote the variable later. the expression still evaluated to false, then you overwrote it with true in the next line.
– r3wt
May 13 '14 at 21:50
2
2
Actually, he was right. First,
$f gets assigned false - but the condition evaluates to true, so then $f is overwritten. If the condition evaluated to false, $f would never been overwritten either way.– ahouse101
Jun 29 '14 at 23:58
Actually, he was right. First,
$f gets assigned false - but the condition evaluates to true, so then $f is overwritten. If the condition evaluated to false, $f would never been overwritten either way.– ahouse101
Jun 29 '14 at 23:58
It's ridiculous to suggest the developers should follow their own taste. Forget the nightmare of another developer trying to maintain the same code, the developer who wrote the code itself would be making semantic mistakes in any code written because s/he preferred
and over &&, where and works as expected in only some situations and && works as expected in all situations.– ADTC
Sep 7 '18 at 19:49
It's ridiculous to suggest the developers should follow their own taste. Forget the nightmare of another developer trying to maintain the same code, the developer who wrote the code itself would be making semantic mistakes in any code written because s/he preferred
and over &&, where and works as expected in only some situations and && works as expected in all situations.– ADTC
Sep 7 '18 at 19:49
add a comment |
For safety, I always parenthesise my comparisons and space them out. That way, I don't have to rely on operator precedence:
if(
((i==0) && (b==2))
||
((c==3) && !(f==5))
)
4
Very safe. Good.
– MarcoZen
Jul 5 '13 at 16:56
26
Personally I think adding extra unnecessary parentheses makes it more confusing to read than having just what you need. For example, I think this is much easier to read: if (($i == 0 && $b == 2) || ($c == 3 && $f != 5))
– rooby
May 11 '14 at 7:40
i agree @rooby that is much easier for me to read as well.
– r3wt
May 13 '14 at 21:52
3
I think this is the prettiest piece of code I've looked at all day. Good job.
– rm-vanda
Dec 30 '14 at 22:58
As PHP is an interpreted language it will run fast if you don't use unnecessary whitespaces or new lines on your code. If you do the same on a compiled language it only will take more time to compile but it will not take effect on runtime. I don't mean doing it once will mark a difference but on an entire application using php + javascript both wrote like the example... load times will be larger for sure. Explanation: Whitespaces and new lines are ignored, but to ignore them, they have to be checked. This happens at runtime on interpreted langs and when compiling on a compiled ones.
– JoelBonetR
Apr 6 '18 at 19:12
|
show 3 more comments
For safety, I always parenthesise my comparisons and space them out. That way, I don't have to rely on operator precedence:
if(
((i==0) && (b==2))
||
((c==3) && !(f==5))
)
4
Very safe. Good.
– MarcoZen
Jul 5 '13 at 16:56
26
Personally I think adding extra unnecessary parentheses makes it more confusing to read than having just what you need. For example, I think this is much easier to read: if (($i == 0 && $b == 2) || ($c == 3 && $f != 5))
– rooby
May 11 '14 at 7:40
i agree @rooby that is much easier for me to read as well.
– r3wt
May 13 '14 at 21:52
3
I think this is the prettiest piece of code I've looked at all day. Good job.
– rm-vanda
Dec 30 '14 at 22:58
As PHP is an interpreted language it will run fast if you don't use unnecessary whitespaces or new lines on your code. If you do the same on a compiled language it only will take more time to compile but it will not take effect on runtime. I don't mean doing it once will mark a difference but on an entire application using php + javascript both wrote like the example... load times will be larger for sure. Explanation: Whitespaces and new lines are ignored, but to ignore them, they have to be checked. This happens at runtime on interpreted langs and when compiling on a compiled ones.
– JoelBonetR
Apr 6 '18 at 19:12
|
show 3 more comments
For safety, I always parenthesise my comparisons and space them out. That way, I don't have to rely on operator precedence:
if(
((i==0) && (b==2))
||
((c==3) && !(f==5))
)
For safety, I always parenthesise my comparisons and space them out. That way, I don't have to rely on operator precedence:
if(
((i==0) && (b==2))
||
((c==3) && !(f==5))
)
answered Nov 13 '12 at 14:06
Captain KenpachiCaptain Kenpachi
4,35553350
4,35553350
4
Very safe. Good.
– MarcoZen
Jul 5 '13 at 16:56
26
Personally I think adding extra unnecessary parentheses makes it more confusing to read than having just what you need. For example, I think this is much easier to read: if (($i == 0 && $b == 2) || ($c == 3 && $f != 5))
– rooby
May 11 '14 at 7:40
i agree @rooby that is much easier for me to read as well.
– r3wt
May 13 '14 at 21:52
3
I think this is the prettiest piece of code I've looked at all day. Good job.
– rm-vanda
Dec 30 '14 at 22:58
As PHP is an interpreted language it will run fast if you don't use unnecessary whitespaces or new lines on your code. If you do the same on a compiled language it only will take more time to compile but it will not take effect on runtime. I don't mean doing it once will mark a difference but on an entire application using php + javascript both wrote like the example... load times will be larger for sure. Explanation: Whitespaces and new lines are ignored, but to ignore them, they have to be checked. This happens at runtime on interpreted langs and when compiling on a compiled ones.
– JoelBonetR
Apr 6 '18 at 19:12
|
show 3 more comments
4
Very safe. Good.
– MarcoZen
Jul 5 '13 at 16:56
26
Personally I think adding extra unnecessary parentheses makes it more confusing to read than having just what you need. For example, I think this is much easier to read: if (($i == 0 && $b == 2) || ($c == 3 && $f != 5))
– rooby
May 11 '14 at 7:40
i agree @rooby that is much easier for me to read as well.
– r3wt
May 13 '14 at 21:52
3
I think this is the prettiest piece of code I've looked at all day. Good job.
– rm-vanda
Dec 30 '14 at 22:58
As PHP is an interpreted language it will run fast if you don't use unnecessary whitespaces or new lines on your code. If you do the same on a compiled language it only will take more time to compile but it will not take effect on runtime. I don't mean doing it once will mark a difference but on an entire application using php + javascript both wrote like the example... load times will be larger for sure. Explanation: Whitespaces and new lines are ignored, but to ignore them, they have to be checked. This happens at runtime on interpreted langs and when compiling on a compiled ones.
– JoelBonetR
Apr 6 '18 at 19:12
4
4
Very safe. Good.
– MarcoZen
Jul 5 '13 at 16:56
Very safe. Good.
– MarcoZen
Jul 5 '13 at 16:56
26
26
Personally I think adding extra unnecessary parentheses makes it more confusing to read than having just what you need. For example, I think this is much easier to read: if (($i == 0 && $b == 2) || ($c == 3 && $f != 5))
– rooby
May 11 '14 at 7:40
Personally I think adding extra unnecessary parentheses makes it more confusing to read than having just what you need. For example, I think this is much easier to read: if (($i == 0 && $b == 2) || ($c == 3 && $f != 5))
– rooby
May 11 '14 at 7:40
i agree @rooby that is much easier for me to read as well.
– r3wt
May 13 '14 at 21:52
i agree @rooby that is much easier for me to read as well.
– r3wt
May 13 '14 at 21:52
3
3
I think this is the prettiest piece of code I've looked at all day. Good job.
– rm-vanda
Dec 30 '14 at 22:58
I think this is the prettiest piece of code I've looked at all day. Good job.
– rm-vanda
Dec 30 '14 at 22:58
As PHP is an interpreted language it will run fast if you don't use unnecessary whitespaces or new lines on your code. If you do the same on a compiled language it only will take more time to compile but it will not take effect on runtime. I don't mean doing it once will mark a difference but on an entire application using php + javascript both wrote like the example... load times will be larger for sure. Explanation: Whitespaces and new lines are ignored, but to ignore them, they have to be checked. This happens at runtime on interpreted langs and when compiling on a compiled ones.
– JoelBonetR
Apr 6 '18 at 19:12
As PHP is an interpreted language it will run fast if you don't use unnecessary whitespaces or new lines on your code. If you do the same on a compiled language it only will take more time to compile but it will not take effect on runtime. I don't mean doing it once will mark a difference but on an entire application using php + javascript both wrote like the example... load times will be larger for sure. Explanation: Whitespaces and new lines are ignored, but to ignore them, they have to be checked. This happens at runtime on interpreted langs and when compiling on a compiled ones.
– JoelBonetR
Apr 6 '18 at 19:12
|
show 3 more comments
Since and has lower precedence than = you can use it in condition assignment:
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
add a comment |
Since and has lower precedence than = you can use it in condition assignment:
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
add a comment |
Since and has lower precedence than = you can use it in condition assignment:
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
Since and has lower precedence than = you can use it in condition assignment:
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
answered Jan 8 '16 at 7:58
JustinasJustinas
27.5k33560
27.5k33560
add a comment |
add a comment |
Precedence differs between && and and (&& has higher precedence than and), something that causes confusion when combined with a ternary operator. For instance,
$predA && $predB ? "foo" : "bar"
will return a string whereas
$predA and $predB ? "foo" : "bar"
will return a boolean.
add a comment |
Precedence differs between && and and (&& has higher precedence than and), something that causes confusion when combined with a ternary operator. For instance,
$predA && $predB ? "foo" : "bar"
will return a string whereas
$predA and $predB ? "foo" : "bar"
will return a boolean.
add a comment |
Precedence differs between && and and (&& has higher precedence than and), something that causes confusion when combined with a ternary operator. For instance,
$predA && $predB ? "foo" : "bar"
will return a string whereas
$predA and $predB ? "foo" : "bar"
will return a boolean.
Precedence differs between && and and (&& has higher precedence than and), something that causes confusion when combined with a ternary operator. For instance,
$predA && $predB ? "foo" : "bar"
will return a string whereas
$predA and $predB ? "foo" : "bar"
will return a boolean.
edited Aug 8 '12 at 9:04
answered Aug 8 '12 at 8:59
arvimanarviman
3,5442737
3,5442737
add a comment |
add a comment |
which version are you using?
If the coding standards for the particular codebase I am writing code for specifies which operator should be used, I'll definitely use that. If not, and the code dictates which should be used (not often, can be easily worked around) then I'll use that. Otherwise, probably &&.
Is 'and' more readable than '&&'?
Is it more readable to you. The answer is yes and no depending on many factors including the code around the operator and indeed the person reading it!
|| there is ~ difference?
Yes. See logical operators for || and bitwise operators for ~.
add a comment |
which version are you using?
If the coding standards for the particular codebase I am writing code for specifies which operator should be used, I'll definitely use that. If not, and the code dictates which should be used (not often, can be easily worked around) then I'll use that. Otherwise, probably &&.
Is 'and' more readable than '&&'?
Is it more readable to you. The answer is yes and no depending on many factors including the code around the operator and indeed the person reading it!
|| there is ~ difference?
Yes. See logical operators for || and bitwise operators for ~.
add a comment |
which version are you using?
If the coding standards for the particular codebase I am writing code for specifies which operator should be used, I'll definitely use that. If not, and the code dictates which should be used (not often, can be easily worked around) then I'll use that. Otherwise, probably &&.
Is 'and' more readable than '&&'?
Is it more readable to you. The answer is yes and no depending on many factors including the code around the operator and indeed the person reading it!
|| there is ~ difference?
Yes. See logical operators for || and bitwise operators for ~.
which version are you using?
If the coding standards for the particular codebase I am writing code for specifies which operator should be used, I'll definitely use that. If not, and the code dictates which should be used (not often, can be easily worked around) then I'll use that. Otherwise, probably &&.
Is 'and' more readable than '&&'?
Is it more readable to you. The answer is yes and no depending on many factors including the code around the operator and indeed the person reading it!
|| there is ~ difference?
Yes. See logical operators for || and bitwise operators for ~.
answered May 10 '10 at 14:52
salathesalathe
43.9k989120
43.9k989120
add a comment |
add a comment |
Let me explain the difference between “and” - “&&” - "&".
"&&" and "and" both are logical AND operations and they do the same thing, but the operator precedence is different.
The precedence (priority) of an operator specifies how "tightly" it binds two expressions together. For example, in the expression 1 + 5 * 3, the answer is 16 and not 18 because the multiplication ("*") operator has a higher precedence than the addition ("+") operator.
Mixing them together in single operation, could give you unexpected results in some cases
I recommend always using &&, but that's your choice.
On the other hand "&" is a bitwise AND operation. It's used for the evaluation and manipulation of specific bits within the integer value.
Example if you do (14 & 7) the result would be 6.
7 = 0111
14 = 1110
------------
= 0110 == 6
add a comment |
Let me explain the difference between “and” - “&&” - "&".
"&&" and "and" both are logical AND operations and they do the same thing, but the operator precedence is different.
The precedence (priority) of an operator specifies how "tightly" it binds two expressions together. For example, in the expression 1 + 5 * 3, the answer is 16 and not 18 because the multiplication ("*") operator has a higher precedence than the addition ("+") operator.
Mixing them together in single operation, could give you unexpected results in some cases
I recommend always using &&, but that's your choice.
On the other hand "&" is a bitwise AND operation. It's used for the evaluation and manipulation of specific bits within the integer value.
Example if you do (14 & 7) the result would be 6.
7 = 0111
14 = 1110
------------
= 0110 == 6
add a comment |
Let me explain the difference between “and” - “&&” - "&".
"&&" and "and" both are logical AND operations and they do the same thing, but the operator precedence is different.
The precedence (priority) of an operator specifies how "tightly" it binds two expressions together. For example, in the expression 1 + 5 * 3, the answer is 16 and not 18 because the multiplication ("*") operator has a higher precedence than the addition ("+") operator.
Mixing them together in single operation, could give you unexpected results in some cases
I recommend always using &&, but that's your choice.
On the other hand "&" is a bitwise AND operation. It's used for the evaluation and manipulation of specific bits within the integer value.
Example if you do (14 & 7) the result would be 6.
7 = 0111
14 = 1110
------------
= 0110 == 6
Let me explain the difference between “and” - “&&” - "&".
"&&" and "and" both are logical AND operations and they do the same thing, but the operator precedence is different.
The precedence (priority) of an operator specifies how "tightly" it binds two expressions together. For example, in the expression 1 + 5 * 3, the answer is 16 and not 18 because the multiplication ("*") operator has a higher precedence than the addition ("+") operator.
Mixing them together in single operation, could give you unexpected results in some cases
I recommend always using &&, but that's your choice.
On the other hand "&" is a bitwise AND operation. It's used for the evaluation and manipulation of specific bits within the integer value.
Example if you do (14 & 7) the result would be 6.
7 = 0111
14 = 1110
------------
= 0110 == 6
answered Nov 22 '17 at 23:37
Mahmoud ZaltMahmoud Zalt
14.8k46057
14.8k46057
add a comment |
add a comment |
I guess it's a matter of taste, although (mistakenly) mixing them up might cause some undesired behaviors:
true && false || false; // returns false
true and false || false; // returns true
Hence, using && and || is safer for they have the highest precedence. In what regards to readability, I'd say these operators are universal enough.
UPDATE: About the comments saying that both operations return false ... well, in fact the code above does not return anything, I'm sorry for the ambiguity. To clarify: the behavior in the second case depends on how the result of the operation is used. Observe how the precedence of operators comes into play here:
var_dump(true and false || false); // bool(false)
$a = true and false || false; var_dump($a); // bool(true)
The reason why $a === true is because the assignment operator has precedence over any logical operator, as already very well explained in other answers.
15
This isn't true, they all return false.
– Jay
Feb 22 '13 at 0:26
1
-1 I think @Jay is right.
– giannis christofakis
Jul 9 '13 at 9:50
add a comment |
I guess it's a matter of taste, although (mistakenly) mixing them up might cause some undesired behaviors:
true && false || false; // returns false
true and false || false; // returns true
Hence, using && and || is safer for they have the highest precedence. In what regards to readability, I'd say these operators are universal enough.
UPDATE: About the comments saying that both operations return false ... well, in fact the code above does not return anything, I'm sorry for the ambiguity. To clarify: the behavior in the second case depends on how the result of the operation is used. Observe how the precedence of operators comes into play here:
var_dump(true and false || false); // bool(false)
$a = true and false || false; var_dump($a); // bool(true)
The reason why $a === true is because the assignment operator has precedence over any logical operator, as already very well explained in other answers.
15
This isn't true, they all return false.
– Jay
Feb 22 '13 at 0:26
1
-1 I think @Jay is right.
– giannis christofakis
Jul 9 '13 at 9:50
add a comment |
I guess it's a matter of taste, although (mistakenly) mixing them up might cause some undesired behaviors:
true && false || false; // returns false
true and false || false; // returns true
Hence, using && and || is safer for they have the highest precedence. In what regards to readability, I'd say these operators are universal enough.
UPDATE: About the comments saying that both operations return false ... well, in fact the code above does not return anything, I'm sorry for the ambiguity. To clarify: the behavior in the second case depends on how the result of the operation is used. Observe how the precedence of operators comes into play here:
var_dump(true and false || false); // bool(false)
$a = true and false || false; var_dump($a); // bool(true)
The reason why $a === true is because the assignment operator has precedence over any logical operator, as already very well explained in other answers.
I guess it's a matter of taste, although (mistakenly) mixing them up might cause some undesired behaviors:
true && false || false; // returns false
true and false || false; // returns true
Hence, using && and || is safer for they have the highest precedence. In what regards to readability, I'd say these operators are universal enough.
UPDATE: About the comments saying that both operations return false ... well, in fact the code above does not return anything, I'm sorry for the ambiguity. To clarify: the behavior in the second case depends on how the result of the operation is used. Observe how the precedence of operators comes into play here:
var_dump(true and false || false); // bool(false)
$a = true and false || false; var_dump($a); // bool(true)
The reason why $a === true is because the assignment operator has precedence over any logical operator, as already very well explained in other answers.
edited May 25 '14 at 22:23
answered May 10 '10 at 14:32
nuqqsanuqqsa
4,18812028
4,18812028
15
This isn't true, they all return false.
– Jay
Feb 22 '13 at 0:26
1
-1 I think @Jay is right.
– giannis christofakis
Jul 9 '13 at 9:50
add a comment |
15
This isn't true, they all return false.
– Jay
Feb 22 '13 at 0:26
1
-1 I think @Jay is right.
– giannis christofakis
Jul 9 '13 at 9:50
15
15
This isn't true, they all return false.
– Jay
Feb 22 '13 at 0:26
This isn't true, they all return false.
– Jay
Feb 22 '13 at 0:26
1
1
-1 I think @Jay is right.
– giannis christofakis
Jul 9 '13 at 9:50
-1 I think @Jay is right.
– giannis christofakis
Jul 9 '13 at 9:50
add a comment |
Here's a little counter example:
$a = true;
$b = true;
$c = $a & $b;
var_dump(true === $c);
output:
bool(false)
I'd say this kind of typo is far more likely to cause insidious problems (in much the same way as = vs ==) and is far less likely to be noticed than adn/ro typos which will flag as syntax errors. I also find and/or is much easier to read. FWIW, most PHP frameworks that express a preference (most don't) specify and/or. I've also never run into a real, non-contrived case where it would have mattered.
add a comment |
Here's a little counter example:
$a = true;
$b = true;
$c = $a & $b;
var_dump(true === $c);
output:
bool(false)
I'd say this kind of typo is far more likely to cause insidious problems (in much the same way as = vs ==) and is far less likely to be noticed than adn/ro typos which will flag as syntax errors. I also find and/or is much easier to read. FWIW, most PHP frameworks that express a preference (most don't) specify and/or. I've also never run into a real, non-contrived case where it would have mattered.
add a comment |
Here's a little counter example:
$a = true;
$b = true;
$c = $a & $b;
var_dump(true === $c);
output:
bool(false)
I'd say this kind of typo is far more likely to cause insidious problems (in much the same way as = vs ==) and is far less likely to be noticed than adn/ro typos which will flag as syntax errors. I also find and/or is much easier to read. FWIW, most PHP frameworks that express a preference (most don't) specify and/or. I've also never run into a real, non-contrived case where it would have mattered.
Here's a little counter example:
$a = true;
$b = true;
$c = $a & $b;
var_dump(true === $c);
output:
bool(false)
I'd say this kind of typo is far more likely to cause insidious problems (in much the same way as = vs ==) and is far less likely to be noticed than adn/ro typos which will flag as syntax errors. I also find and/or is much easier to read. FWIW, most PHP frameworks that express a preference (most don't) specify and/or. I've also never run into a real, non-contrived case where it would have mattered.
answered Jun 25 '17 at 21:00
SynchroSynchro
18.6k85371
18.6k85371
add a comment |
add a comment |
Depending on the language that you are using, generally it is better practice to use
&&and||rather thanandandor, except in languages like Python, whereandandorare used instead and&&and||do not exist.
add a comment |
Depending on the language that you are using, generally it is better practice to use
&&and||rather thanandandor, except in languages like Python, whereandandorare used instead and&&and||do not exist.
add a comment |
Depending on the language that you are using, generally it is better practice to use
&&and||rather thanandandor, except in languages like Python, whereandandorare used instead and&&and||do not exist.
Depending on the language that you are using, generally it is better practice to use
&&and||rather thanandandor, except in languages like Python, whereandandorare used instead and&&and||do not exist.
answered Jan 1 '18 at 14:25
Aryan BeezadhurAryan Beezadhur
1817
1817
add a comment |
add a comment |
Another nice example using if statements without = assignment operations.
if (true || true && false); // is the same as:
if (true || (true && false)); // TRUE
and
if (true || true AND false); // is the same as:
if ((true || true) && false); // FALSE
because AND has a lower precedence and thus || a higher precedence.
These are different in the cases of true, false, false and true, true, false.
See https://ideone.com/lsqovs for en elaborate example.
add a comment |
Another nice example using if statements without = assignment operations.
if (true || true && false); // is the same as:
if (true || (true && false)); // TRUE
and
if (true || true AND false); // is the same as:
if ((true || true) && false); // FALSE
because AND has a lower precedence and thus || a higher precedence.
These are different in the cases of true, false, false and true, true, false.
See https://ideone.com/lsqovs for en elaborate example.
add a comment |
Another nice example using if statements without = assignment operations.
if (true || true && false); // is the same as:
if (true || (true && false)); // TRUE
and
if (true || true AND false); // is the same as:
if ((true || true) && false); // FALSE
because AND has a lower precedence and thus || a higher precedence.
These are different in the cases of true, false, false and true, true, false.
See https://ideone.com/lsqovs for en elaborate example.
Another nice example using if statements without = assignment operations.
if (true || true && false); // is the same as:
if (true || (true && false)); // TRUE
and
if (true || true AND false); // is the same as:
if ((true || true) && false); // FALSE
because AND has a lower precedence and thus || a higher precedence.
These are different in the cases of true, false, false and true, true, false.
See https://ideone.com/lsqovs for en elaborate example.
edited Jul 19 '18 at 12:56
answered Jul 19 '18 at 12:51
KenKen
7373819
7373819
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f2803321%2fand-vs-as-operator%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Note that
~is the bit-wise NOT operator and not the logical. ;-)– Gumbo
May 10 '10 at 14:26
2
Yes, i know. Bad habits :) . It is a little bit strange that in PHP there are 'and', 'or' and 'xor', but there is no 'not', isn't it?
– ts.
May 12 '10 at 10:30
1
@ts: the correct answer here is the one provided by R. Bemrose stackoverflow.com/questions/2803321/and-vs-as-operator/…
– Marco Demaio
May 24 '11 at 15:45
4
! is the logical not operator
– Razor Storm
May 30 '11 at 8:15
2
@chiliNUT quite right. At the time it must have made sense. Looks like the lurking incorrect answer has been punished at this point :)
– doublejosh
Mar 28 '14 at 19:34