порядок выражения реляционного оператора

StackOverflow https://stackoverflow.com/questions/91994

  •  01-07-2019
  •  | 
  •  

Вопрос

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

if (0 == someVariable)

В отличие от того, что я обычно вижу / пишу:

if (someVariable == 0)

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

Это было полезно?

Решение

Я понимаю, что это личные предпочтения.Хотя, поместив переменную second, вы можете быть уверены, что случайно не присвоите константу переменной, которая использовалась разработчиками c.Вероятно, именно поэтому вы видите это в c #, когда разработчики переключают язык.

Другие советы

Порядок не имеет значения, однако, в первом случае предполагается, что она с нуля вы проверяете.Конвенция диктует использование последнего.

Основная причина в C и C ++ заключается в том, что его легко вводить

if (someVariable = 0) {
    ...
}

который всегда терпит неудачу, а также устанавливает someVariable до 0.

Лично я предпочитаю стиль variable-first, потому что он читается более естественно, и просто надеюсь, что я не забуду использовать == нет =.

Многие компиляторы C и C ++ выдадут предупреждение, если вы назначите константу внутри if.Java и C # избегают этой проблемы, запрещая небулевые выражения в if пункты.Python позволяет избежать этой проблемы, делая присваивания оператором, а не выражением.

Первый метод существует как способ напомнить себе, что не следует выполнять присваивания в операторе IF, что может иметь катастрофические последствия в некоторых языках (C / C ++).В C # это заинтересует вас только в том случае, если вы задаете логические значения.

Потенциально фатальный код на языке Си:

if (succeeded = TRUE)
{
    // I could be in trouble here if 'succeeded' was FALSE
}

В C / C ++ любая переменная подвержена этой проблеме VAR = CONSTANT, когда вы предполагали, что VAR == CONSTANT .Таким образом, часто принято изменять порядок вашего оператора IF, чтобы получить ошибку компиляции, если вы ошибетесь с этим:

if (TRUE = succeeded)
{
    // This will fail to compile, and I'll fix my mistake
}

В C # этому подвержены только логические значения, поскольку в операторе if допустимы только логические выражения.

if (myInteger = 9)
{
    // this will fail to compile
}

Итак, в мире C # нет необходимости использовать стиль CONSTANT == VAR, если только вам это не удобно.

В дополнение к равенству я часто сталкиваюсь с таким кодом, как

if (0 > number)

или

if (NULL != pointer)

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

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

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

Однако в C # вы не можете сделать это непреднамеренно, так что на самом деле это не имеет значения.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top