Порядок сравниваемых предметов?

Question

Я видел это вокруг, но никогда не слышал четкого объяснения того, почему ... Это действительно для любого языка, не только для C # или VB.NET, или для Perl, или для чего-либо еще.

При сравнении двух элементов иногда значение «check» ставится слева, а не справа. По логике для меня вы сначала перечислите свою переменную, а затем значение, с которым вы сравниваете. Но я видел обратное, где «константа» указана первой.

Какой (если есть) выигрыш в этом методе?

Так что вместо:

if (myValue > 0)

Я видел:

if (0 < myValue)

или

if (Object.GimmeAnotherObject() != null)

заменяется на:

if (null != Object.GimmeAnotherObject())

Есть идеи по этому поводу?

TIA! Kevin

Answer 1

Некоторые разработчики ставят константу слева примерно так

if(0 = myValue)

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

if(0 == myValue)

Это предотвращает множество болезненных отладок в будущем, поскольку

if(myValue = 0)

совершенно законно, но, скорее всего, вы имели в виду

if(myValue == 0)

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

Answer 2

Для .Net это не имеет значения, так как компилятор не позволит вам выполнить присваивание в таком состоянии, как:

if(x=1)

потому что (как все говорили) это плохая практика (потому что ее легко пропустить).

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

Answer 3

В C ++ оба они действительны и компилируются

if(x == 1)

и

if(x=1)

но если ты напишешь это так

if(1==x)

и

if(1=x)

тогда присваивается 1, и код не компилируется.

Считать «безопаснее» помещать переменную const в левую часть.

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

Answer 4

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

if ((low <= value) && (value <= high))
{
    DoStuff(value);
}

Но я согласен с примерами, которые вы упомянули - я бы хотел, чтобы константа была последней и не вижу никакой очевидной причины делать это иначе.

if (object != null)
{
    DoStuff(object);
}

Answer 5

Это практика кодирования, чтобы ловить опечатки, например, '! =', Напечатанные как '='.

Если у вас слева есть CONSTANT, все операторы присваивания будут перехвачены компилятором, поскольку вы не можете присвоить константу.

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

if (var1 = (var2 & var3)) { /* do something */ }

Этот код получит логический результат в var1, а также / * сделает что-то * /, если результат равен true.

Связанная практика кодирования заключается в том, чтобы избегать написания кода, в котором условные выражения имеют присваивания внутри них; хотя язык программирования допускает такие вещи. Вы не часто сталкиваетесь с таким кодом, поскольку присваивания в условных выражениях необычны, поэтому в типичном коде таких вещей нет.

На сайте IBM DeveloperWorks есть хорошая статья C о практике кодирования языка, которая, вероятно, все еще актуальна для людей, пишущих на этом языке.