Подтвердить что ты не робот

Почему некоторые опытные программисты пишут сравнения со значением перед переменной?

Возможные дубликаты:
Как проверить равные? (0 == i) или (i == 0)
Почему в С# часто видят "null!= variable" вместо "variable!= null" ?

Я смотрел на нечетный учебник здесь и там, а также на некоторый код DirectX и заметил, что многие опытные программисты на C++ пишут выражения следующим образом:

(<constant> == <variable>)

а не то, что предпочитает моя обычная мудрость:

(<variable> == <constant>)

например. if (NULL == ptr), а не if (ptr == NULL). Я предпочитаю вторую альтернативу, если нет других причин для выбора первого, моя причина в том, что переменная, кажется, является "получающим" концом выражения.

Но я подозреваю, что первый используется, чтобы избежать непреднамеренного назначения значения константы переменной с помощью =, а не ==. Правильно ли это?

4b9b3361

ОТВЕТЫ

Ответ 1

Да, это правильно. Чтобы определить опечатку = вместо ==.

Ответ 2

Это было так, да. Конечно, в настоящее время почти все компиляторы предупреждают о назначениях в условиях if(), поэтому преимущество есть только для людей, которые обычно подавляют предупреждения.

Ответ 3

потому что вы не можете назначить значение константе, поэтому, если по ошибке вы помещаете = вместо ==, компилятор выдает ошибку, предупреждая вас

Ответ 4

Это было названо как "Yoda Conditional"!

См. здесь https://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined

Мне очень нравится этот термин, потому что:

if(Light::On == light)

Считывается как:

"Если включено свет"

Как уже говорилось, это используется для предотвращения неправильного присвоения. Можно утверждать, что эта практика является архаичной на основе современных IDE, но я по-прежнему считаю, что это хорошая практика.

Ответ 5

Это обычное оправдание, так же как и аргумент, что вы не хотите толкать константу в крайнем правом углу экрана с выраженным выражением. Последний аргумент никогда не казался мне особенно убедительным, и первое не действительно действительно в наши дни, поскольку любой уважающий себя компилятор выдаст предупреждения (вы компилируете с предупреждениями как ошибки, не так ли?:-).

EDIT: я просто просмотрел новый предварительный просмотр Xcode 4 и просто посмотрю на пример, который они выбрали, чтобы продемонстрировать свою новую функцию "Fix-it"!

alt text http://devimages.apple.com/technologies/tools/images/new_autocorrect20100721.jpg

Ответ 6

Чтобы понять разницу между назначением и сравнением.

Если вы имеете в виду:

if (ptr == foo)

но введите

if (ptr = foo)

если все равно будет действительным кодом, так как ptr = foo будет оценивать логическую проверку на ptr после того, как она будет установлена ​​в значение foo. Очевидно, вы не хотите этого.

Тем не менее, я нахожу, что это сильно ухудшает читаемость, и учитывая, что большинство IDE и препроцессоров все равно поймают это, никогда не используйте этот стиль.

Ответ 7

Это позволяет избежать написания var = NULL. Запись NULL = var приведет к ошибке. Итак, вы правы: -)

Ответ 9

Назначение уловки является основной причиной использования условий Yoda, но есть и другие. В С++ оператор вызывается в операнде LHS. Поскольку константы обычно const (duh) или примитивы, это ограничивает возможность нечувствительных операций. Один пример: = в примитивном литерале, например, общая причина (1 = a), но это будет включать operator=() const или любой другой оператор, используемый для не-POD-типов.

Ответ 10

С таким языком, как VB 6.0, который не имеет отдельных операторов присваивания и сравнения,

a = 2

'Будет компилироваться, независимо от того, имеете ли вы, что присвоено 2 или сравниваете ли вы с 2 Если вы хотите сравнить, существует вероятность того, что возникнет ошибка времени выполнения.

'Для назначения, если вы всегда пишете

a = 2

'И для назначения, если вы всегда пишете

2 = a

'Вы исключаете сценарий компиляции и сценарий времени выполнения.

Но это только совет: визуальный намек недоступен, если у вас есть выражение типа

a = b 'Сравнение или присвоение?

С# имеет: - различное присвоение (=) и сравнение (==) символов - сравнения должны быть заключены в скобки.

Затем это становится проблемой.

Ответ 11

Потому что они знают, что они делают: P

Ответ 12

Вы правы - это вызвать ошибку компилятора, если вы ошиблись "==" как "=", так как присваивание всегда будет возвращать true. Хотя это, как правило, легко заметить и отлаживать, время от времени будет очень сложно обнаружить ошибку, подумайте об этом:

#define OK 2 // Or something...
[...]
while(status = OK){
    // This loop will never end
    // Even if you change the value of status within it
    [...]
}

Это может быть неприятная ошибка, особенно если блок, относящийся к оскорбительному выражению, длинный (представьте, что вы ищете все возможные причины, по которым статус всегда остается в порядке).

Если, с другой стороны, вы использовали:

while(OK = status){

Это вызовет ошибку компилятора, поскольку вы не можете присвоить значение константе.

Эта практика иногда упоминается как условия Йоды, поскольку она сопоставляет объект и объект. Как "если статус в порядке" против "если ОК - это состояние" и "небо голубое", а "синее небо" - последнее, что может сказать Йода.

Ответ 13

Как разработчик Java, я предпочитаю писать такие выражения:

   //primitive check
   if(constant == variable)

   //Object check
   if(constant.equals(variable))

Это особенно важно для объекта, потому что выражение не является ошибкой, если переменная имеет значение null. Если бы выражение находилось в другом порядке, ошибка в null была бы ошибкой. Я поддерживаю согласованность и выполняю тот же порядок для примитивов.