Prefer != to <> for NOT EQUALS in PHP

+1. While I learned not equals as <> I prefer !=.

Wow, I really thought that was already a standard. I double checked and don't see it. Weird.

+1

Realistically +1, given https://stackoverflow.com/posts/723426/revisions but yeah != is not ANSI SQL

Realistically +1, given https://stackoverflow.com/posts/723426/revisions but yeah != is not ANSI SQL

I thought they were talking about SQL operators, too, but those are already regulated (although Views violates it) and it seems there indeed is a <> PHP operator! Never heard of it before, though, nor seen it (I'm pretty sure).

So, yes, definitely +1! Having this in the code somewhere would be a huge WTF.

Updating IS with a concrete proposal.

Oh wow, I got totally confused. +10 for that.

Generally +1.

Some notes that we might want to mention in the doc page:

• While || and or have different operator precedence, != and <> apparently have the same operator precedence.
• When given a choice, always pick the strong-typed comparison operators, === or !==.
  Maybe this does not really belong on the "coding standards" page, but it is, I think, an important thing to learn for Drupal developers.

While || and or have different operator precedence, != and <> apparently have the same operator precedence.

I don't think we need to note that – why would we? If people shouldn't use the operator, its precedence is irrelevant. And if they are frantically searching for a reason to allow it after all, they'll soon discover there is none themselves, without us pointing it out.

When given a choice, always pick the strong-typed comparison operators, === or !==.

That seems like a completely different issue – and one far less clear-cut, I'd say.

Would be nice to add a note about using <> for SQL to this. I was confused as well...

> If people shouldn't use the operator, its precedence is irrelevant

"You don't need the <> operator as its precedence is the same as != so please use !="

+1

So this issue is now in phase 4, right?
I guess the next step is logically step 5, so let's see when something happens next.

Discussed at the August 9th coding standards committee meeting, and ratified.

As there were no immediately identifiable occurrences of this in core, this does not appear to affect core (i.e. is presumed as an existing defacto core policy), and is thus promoted to step 8 of the coding standards process.

I updated the documentation, marking fixed!