В чем разница между ними (bCondition == NULL) и (NULL == bCondition)?

Ответ 1

Использование NULL == condition обеспечивает более полезное поведение в случае опечатки, когда оператор присваивания = используется случайно, а не оператор сравнения ==:

if (bCondition = NULL)  // typo here
{
 // code never executes
}

if (NULL = bCondition) //  error -> compiler complains
{
 // ...
}

C-компилятор дает предупреждение в первом случае, таких предупреждений не существует на многих языках.

Ответ 2

Он называется Условия Yoda. (исходная ссылка, вам нужна высокая репутация, чтобы увидеть ее).

Он предназначен для защиты от случайного назначения = в условиях, когда предполагалось сравнение равенства ==. Если вы придерживаетесь Yoda по привычке и делаете опечатку, пишите = вместо ==, код не сможет скомпилироваться, потому что вы не можете назначить rvalue.

Стоит ли это неловко? Некоторые не согласны с тем, что компиляторы выдает предупреждение, когда они видят = в условных выражениях. Я говорю, что это просто случилось всего два или три раза в моей жизни, чтобы сделать эту ошибку, что не оправдывает изменение всех MLOC, которые я написал в своей жизни, на эту конвенцию.

Ответ 3

Многие люди предпочитают писать NULL == bCondition, чтобы они случайно не назначали значение NULL для bCondition.

Из-за опечатки случается, что вместо записи

bCondition == NULL 

они заканчивают писать

bCondition = NULL // the value will be assigned here.

В случае

NULL = bCondition // there will be an error

Ответ 4

Нет никакой разницы. Это древний способ защитного программирования, устаревший уже более 20 лет. Цель состояла в том, чтобы защитить от случайного ввода = вместо == при сравнении двух значений. Программисты Pascal, мигрирующие на C, были особенно склонны писать эту ошибку.

Из Borland Turbo C, выпущенного в 1990 году и вперёд, каждый известный компилятор предупреждает об "возможно неправильном назначении", когда вам удастся напечатать эту ошибку.

Таким образом, запись (NULL == bCondition) не лучше или хуже, чем наоборот, если ваш компилятор не является чрезвычайно древним. Вам не нужно беспокоиться о написании их в любом конкретном порядке.

Вам следует позаботиться о том, чтобы адаптировать стиль кодирования, когда вы никогда не пишете задания внутри if/loop. Для этого никогда не было причин. Это совершенно лишняя, рискованная и уродливая особенность языка C. Все отраслевые стандарты де-факто кодирования запрещают назначение внутри условий.

Ссылки:

• MISRA C: 2004 13.1
• CERT C EXP18-C

Ответ 5

Это просто хорошая оборонительная мера. Некоторым также может быть удобнее читать. В случае ошибочного присваивания вместо оператора равенства компилятор попытается изменить NULL, который не является значением lvalue и выдает сообщение об ошибке. При использовании bCondition = NULL компилятор может выдать предупреждение об использовании назначения в качестве значения истины, сообщение, которое может потеряться и остаться незамеченным.

Ответ 6

Хотя обычно нет разницы между variable == value и value == variable, и в принципе не должно быть, на С++ иногда может быть разница в общем случае, если задействована перегрузка оператора. Например, хотя ожидается, что == будет симметричным, кто-то может написать патологическую реализацию, которая не является.

Строковый класс Microsoft _bstr_t страдает от проблемы асимметрии в реализации operator==.