Почему используются сравнения «задом наперед», например, false == obj.prop.subProp?

Question

[vadimm0s]

Часто встречаю, особенно во всевозможных проверках, в стороннем коде конструкции типа
false == obj.prop.subProp
или
1 == arr[8]
и т.п.
Вроде, как нормальный, воспринимается порядок "что" == "с чем" или "переменная" == "константа". Почему
иногда используются сравнения "задом наперед", например false == obj.prop.subProp?

Comments

[Roman]

С++ тут при чём?

[Максим Федоров]

чтобы случайно не сделать присвоение :) то есть значение, а потом то, что с ним сравниваешь...
ну или еще зачем-то, называется Йода кондишн

[Anton Kuzmichev]

Roman, скорее всего оттуда пошло) я такое раньше видел именно в C/C++ исходниках, еще лет 15 назад.

[Roman]

Anton Kuzmichev, я не про это, я про тэг который уже убрали и поставили подходящий.
А так помимо проблем с операторами присвоения и проверки на равенство в некоторых языках, есть инфа, что это в некоторых случаях улучшает удобочитаемость кода. Если достаточно много ветвлений и/или нетривиальные выражения в условии.

[BorLaze]

Про Йоду Мастера сказали уже.

Еще один момент - в Java, например, сравнение "London".equals(city) не выдаст NullPointerException, если city равна null; в отличие от city.equals("London")

Answer 1

[Developer]

Это называется Yoda-style.
true/false переменной по ошибке случайно не присвоить чтобы.
Слева значение это будет в условии если, компиляции на стадии ошибку получишь ты.

Answer 2

[DevMan]

Условия Йоды

Comments

[vadimm0s]

Понятно стало всё мне теперь.

Answer 3

[d-stream]

Это защита от стрельбы себе в ногу при использовании убогих систем.

if(x=1) прокатит вместо if(x==1), а вот if(1=x) отвалится почти везде

Answer 4

[Вадим Шаталов]

Сути по значения не имеет, юный падаван
Но пишет так кто - к темной стороне силы уже близок он

Comments

[ybqwer]

на тёмную сторону силы, юный падаван , не запись 1 == arr[8] ведёт, но false == obj.prop.subProp вместо
if not obj.prop.subProp