I'd like to propose that we suggest a preference for&& and || for logical operators instead of and and or for consistency and clarity, if precedence is needed for assignment then it would be clearer to use parenthesis.



joelpittet created an issue. See original summary.

drunken monkey’s picture

Thanks for the suggestion! I completely support this. Seems weird we don't already specify this, really.
The only real use for or and and, as you say, is checking assignments, and I personally find that pretty bad style which we should discourage (in my opinion).

However, do you by any chance have any data on how often those are actually used in Core right now?

joelpittet’s picture

In D8 I couldn't find any cases by scanning with this regex. (or|and) [^\w@<%\.#/\* {]

And didn't see anything in D7 core but some sparse ones in ctools, features, eck and a few others.

tizzo’s picture

Title: Logical Operators » Prefer || or && Over `or` or `and` in Logical Operators
Issue tags: +final discussion

Personally, I support this and give it a +1.

The TWG is soliciting input in our next final discussion announcement. Feedback will be reviewed in our meeting on 9/19.

giorgio79’s picture

Using natural language is much more readable and understandable, so -1. Lets not go back to assembly days please.

pfrenssen’s picture

I am personally in favor of this. and and or have the lowest operator precedence in PHP which makes them difficult to use in typical code. For example these lines of code are NOT equivalent:

// Assigns the score if there are more than 10 votes.
$score = isset($item['score']) && $item['votes'] > 10 ? $item['score'] : FALSE;

// Will throw a warning if $item['score'] is not set, and otherwise it will assign TRUE instead of the score.
$score = isset($item['score']) and $item['votes'] > 10 ? $item['score'] : FALSE;

The operator precedence is very carefully designed in PHP to make it as intuitive as possible and to make parentheses unnecessary in the most common use cases.

We already have coding standards in place to disallow coding standards that require the use of parentheses to make them work, for example we disallow inline variable assignments.

Also a very big point in favor is that core is not using and and or at all as mentioned in comment #3. If we are already avoiding its use it is a de-facto standard and it makes sense to formalize this.

In case people are wondering why these operators actually exist in PHP, they are intended to be used when doing an assignment and a comparison in a single step, so that parentheses can be avoided in this case. For example these two lines are equivalent:

if (($entity = Node::load($id)) && $entity->isPublished()) {
  // $entity is available in this scope and we know it is published.

if ($entity = Node::load($id) and $entity->isPublished()) {
  // Thanks to 'and' we don't need to use an extra set of parentheses.

So this is actually useful in this case, but ONLY in this case, and it can be very confusing to people that are not aware of this difference and they use them _without_ doing an inline assignment.

In Drupal we already disallow inline assigments, so there is absolutely no use at all for and and or.

JvE’s picture


pslcbs’s picture

+1 for || and && as logical operators.

james.williams’s picture

Using natural language is much more readable and understandable, so -1. Lets not go back to assembly days please.

The vast majority of core code already uses && and ||. So this isn't about choosing to use 'and' and 'or' instead. Instead, as far as I see it, it's about maintainability & consistency. So In my opinion, its better in that respect to just use one or the other, and as the majority's code already uses && and ||, I support this suggestion.

Perignon’s picture

+1 I never think to type 'and' or 'or'. I have been using && and || for too long. Java (day job) uses the same operators as PHP.

giorgio79’s picture

Still -1. Should be raised upstream with php to move towards natural language instead of random doodles. :D Lots of confusion in php land https://stackoverflow.com/questions/2803321/and-vs-as-operator

loopduplicate’s picture

+1 from me for sure. I have never needed to use "or" or "and".

Side note... isn't there some better way to actually do a +1?

pivica’s picture

+1 from me.

Andrej Galuf’s picture

+1 from me.

jgloverattronedotcom’s picture

+1 for || && instead of "or" and "and"

progga’s picture


I find if ($cheap and $nasty) more readable than if ($cheap && $nasty)

benjifisher’s picture

From Comment #6 above:

In Drupal we already disallow inline assigments, so there is absolutely no use at all for and and or.

I was not aware of that rule, and I cannot find it on https://www.drupal.org/docs/develop/standards/coding-standards. Can you give a reference?

Personally, I like to use the lower status of and to avoid parentheses, as in the last code snippet from Comment #6. If that snippet already violates Drupal standards because of the inline assignment, then I will add my +1 in favor of disallowing and and or.

@progga (Comment #16): Which matters more, personal preference or consistency? We already have a codebase full of && and || ... I see I am repeating Comment #9.

benjifisher’s picture

According to the discussion in #2372543: [policy, no patch] Explicitly disallow yoda conditions, inline assignments are disallowed in JS code, and #2907332: Disallow assignments in conditions was just added to discuss whether to adopt the same standard in PHP code.

That sort of answers my own question.

Gogowitsch’s picture

+1. I am in favor of excluding 'and' and 'or' from Drupal code.

steinmb’s picture

+1 Let us formalize this.

tizzo’s picture

Title: Prefer || or && Over `or` or `and` in Logical Operators » Disallow `or` or `and` in Logical Operators (use `||` or `&&`)

This was discussed on today's Coding Standards Committee meeting. Most of the support here appears to be in formally disallowing the english word forms rather than preferring the other form. As such, we have decided to retitle the issue and leave it open for another two weeks of discussion but barring major dissent we are like to ratify this in two weeks.

borisson_’s picture

+1 to this, I learned about the operator precedence from this issue - I didn't even know that. Readability is important but I feel that this so pushed into our brains what these mean that this doesn't hurt readability.

tizzo’s picture

Status: Needs review » Postponed
Issue tags: -final discussion +approved pending a coder rule

In todays TWG meeting we felt that this issue has sufficient support. Marking postponed and tagging approved pending a coder rule. As soon as we get a patch in the coder queue to enforce this rule we will formally approve, announce, and update documentation.