Disallow `or` or `and` in Logical Operators (use `||` or `&&`)

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?

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.

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

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.

Supported.

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

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.

+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.

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

+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?

+1 from me.

+1 from me.

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

-1

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

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.

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.

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

+1 Let us formalize this.

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.

+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.

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.

I can't find an issue in Coder for this. Is there one?

This has been revived in the Slack thread https://drupal.slack.com/archives/CJ19MV96J/p1738103687296019

From #23

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.

I have updated the issue summary to include the new template, but not filled in any of the details. Anyone else on this thread is welcome to take that on, I'm just giving the template.

Added as supporting.

Since this was approved 7 years, I have gone ahead and made a coder issue, #3503286: Add a sniff to prohibit "or" or "and" as logical operators

Added proposed text for discussion.