Как проверить равные? (0 == i) или (i == 0)

Ответ 1

Я предпочитаю второй, (i == 0), потому что он чувствует себя намного более естественным при чтении. Вы спрашиваете людей: "Вам 21 год или старше?", А не: "Является ли 21 меньше или равно вашему возрасту?"

Ответ 2

В С# это не имеет значения, если вы поместили переменную как в первую, так и в последнюю, потому что присваивания не оцениваются в bool (или что-то, что можно отнести к bool), поэтому компилятор ловит любые ошибки, например: if (i = 0) EntireCompanyData.Delete() "

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

Ответ 3

Если у вас есть список ifs, который не может быть хорошо отображен коммутатором (возможно, из-за ограничения языка), я бы предпочел:

if (InterstingValue1 == foo) { } else
if (InterstingValue2 == foo) { } else
if (InterstingValue3 == foo) { }

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

В частности, в Java я считаю полезным:

if ("SomeValue".equals(someString)) {
}

потому что someString может быть нулевым, и таким образом вы никогда не получите исключение NullPointerException. То же самое применяется, если вы сравниваете константы, которые, как вы знаете, никогда не будут иметь значение null против объектов, которые могут быть пустыми.

Ответ 4

• (0 == i)

Я всегда буду выбирать этот. Это правда, что большинство компиляторов сегодня не разрешают привязку переменной в условном выражении, но правда в том, что некоторые делают. В программировании для Интернета сегодня я должен использовать множество языков в системе. Используя 0 == i, я всегда знаю, что условный оператор будет правильным, и я не полагаюсь на компилятор/интерпретатор, чтобы поймать мою ошибку для меня. Теперь, если мне нужно перейти с С# на С++ или JavaScript, я знаю, что мне не придется отслеживать ошибки присваивания в условных операторах в моем коде. Для чего-то такого маленького и чтобы он сохранял это время, это не проблема.

Ответ 5

Знаете, я всегда использую формат условного выражения if (i == 0), и моя причина для этого заключается в том, что я пишу большую часть своего кода на С# (который будет указывать на другой один в любом случае), и я делаю первый подход к моему развитию, и мои тесты в любом случае поймают эту ошибку.

Я работал в магазинах, где они пытались использовать формат 0 == i, но мне было неловко писать, неудобно вспоминать, и это просто закончилось тем, что я был кормом для рецензентов кода, которые искали низко висящие фрукты.

Ответ 6

Я был убежден, что более читаемым вариантом (i == 0) был лучший способ пойти с.

Затем мы пропустили пробную ошибку (не очень благодарно), где проблема была ошибкой типа ($ var = SOME_CONSTANT). Клиенты начали получать электронную почту, предназначенную для других клиентов. Данные чувствительного типа также.

Вы можете утверждать, что Q/A должен был поймать его, но они этого не сделали, это другая история.

С того дня я всегда настаивал на (0 == i) версии. Это в основном устраняет проблему. Это кажется неестественным, поэтому вы обращаете внимание, поэтому вы не ошибаетесь. Здесь просто нет способа сделать это неправильно.

Также намного легче поймать, что кто-то не отменил оператор if в обзоре кода, чем то, что кто-то случайно присвоил значение в if. Если формат является частью стандартов кодирования, люди его ищут. Люди обычно не отлаживают код во время просмотра кода, и кажется, что глаз просматривает (i = 0) vs an (i == 0).

Я также намного больше поклонник java "Constant String".equals(dynamicString), исключений с нулевым указателем - это хорошо.

Ответ 7

Собственно, пример DialogResult - это место, где я бы рекомендовал этот стиль. Он помещает важную часть if() влево, если это видно. Если он справа, а MessageBox имеет больше параметров (что вполне вероятно), вам может потребоваться прокрутить его, чтобы увидеть его.

OTOH, я никогда не видел много пользы в стиле "(0 == i)". Если вы не могли бы сначала указать константу, вы можете использовать два знака равенства,

Ответ 8

Я пытаюсь всегда использовать 1-й случай (0 == i), и это спасло мою жизнь несколько раз!

Ответ 9

Я думаю, что это всего лишь вопрос стиля. И это помогает при случайном использовании оператора присваивания.

Я бы не стал просить программиста расти, хотя.

Ответ 10

Я предпочитаю (i == 0), но я все же предпочитаю делать "правило" для себя (0 == i), а затем каждый раз прерывать его.

"Э?", вы думаете.

Хорошо, если я принимаю заведомое решение поставить lvalue слева, тогда я уделяю достаточное внимание тому, что я набираю, если я наберу "=" для "==". Я надеюсь. В C/С++ я обычно использую -Wall для своего собственного кода, который в любом случае генерирует предупреждение о gcc для большинства ошибок "=" для "==". Я не помню, чтобы это предупреждение появлялось недавно, возможно, потому, что чем дольше я программирую более рефлексивно параноидально, я об ошибках, которые я сделал раньше...

if(DialogResult.OK == MessageBox.Show("Message"))

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

Но кто скажет, является ли DialogResult.OK более или менее вероятным для оценки назначаемого типа, чем MessageBox.Show( "Сообщение" )? В Java вызов метода не может быть назначен, тогда как поле может быть не окончательным. Поэтому, если вы беспокоитесь о вводе = для ==, в этом примере на Java это должно быть наоборот. В С++ либо нельзя, либо оба могут быть назначены.

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

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

Ответ 11

Я использую (i == 0) по той простой причине, что он читает лучше. Это делает очень плавный поток в моей голове. Когда вы читаете код обратно для себя для отладки или других целей, он просто течет, как чтение книги, и имеет смысл.

Ответ 12

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

Ответ 13

Третий вариант - запретить назначение внутри условных обозначений целиком:

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

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

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

-Adam

Ответ 14

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

Ответ 15

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

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

Ответ 16

оба равны, хотя я предпочел бы немного вариант 0 == i.

при сравнении строк больше подвержено ошибкам сравнивать "MyString".equals(getDynamicString())

поскольку getDynamicString() может возвращать значение null. чтобы быть более постоянными, напишите 0 == i

Ответ 17

Ну, это зависит от языка и компилятора. Контекст - это все.

В Java и С# оговорка "назначение вместо сравнения" заканчивается недействительным кодом, кроме очень редкой ситуации, когда вы сравниваете два булевых значения.

Я могу понять, почему можно хотеть использовать "безопасную" форму в C/С++, но, откровенно говоря, большинство компиляторов C/С++ предупредит вас, если вы сделаете опечатку в любом случае. Если вы используете компилятор, который этого не делает, вы должны спросить себя, почему:)

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

Ответ 18

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

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

if (DateClass.SATURDAY == dateObject.getDayOfWeek())

если getDayOfWeek() возвращает константу (и, следовательно, не lvalue) в любом случае!

Мне повезло (по крайней мере, в этом отношении) в том, что в наши дни я в основном кодирую на Java и, как уже упоминалось, if (someInt = 0) не будет компилироваться.

Предостережение о сравнении двух логических значений - это немного красно-селедка, так как большую часть времени вы либо сравниваете две логические переменные (в этом случае их замена их не помогает) или проверка того, установлен ли флаг, и woe-betide-you, если я поймаю, что вы явно сравниваете что-либо с true или false в ваших условностях! Grrrr!

Ответ 19

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

Я редко вижу большую пользу от читаемости POV.

Ответ 20

Чтение кода является одной из самых важных вещей для кода, превышающего несколько сотен строк, и, безусловно, я == 0 читается намного проще, чем обратная

Ответ 21

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

Ответ 22

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

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

Ответ 23

Я всегда использую второй метод. В С# запись

if (i = 0) {
}

приводит к ошибке компилятора (не может преобразовать int в bool) в любом случае, так что вы можете сделать ошибку, на самом деле не проблема. Если вы протестируете bool, компилятор все равно выдаст предупреждение, и вы не должны сравнивать bool с true или false. Теперь вы знаете, почему.

Ответ 24

Я лично предпочитаю использование формата с переменным-операндом в части, потому что я использую его так долго, что он чувствует себя "естественным" и отчасти потому, что он кажется преобладающим соглашением. Существуют некоторые языки, которые используют операторы присваивания, такие как:

:1 -> x

Таким образом, в контексте этих языков может показаться довольно запутанным видеть следующее, даже если оно действительно:

:if(1=x)

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

Ответ 25

Это один из моих самых больших домашних животных. Нет причин уменьшать удобочитаемость кода (если (0 == i), что? Как можно изменить значение 0?), Чтобы поймать то, что любой компилятор C, написанный за последние двадцать лет, может автоматически улавливаться.

Да, я знаю, большинство компиляторов C и С++ не включили это по умолчанию. Посмотрите на правильный переключатель, чтобы включить его. Нет оправдания тому, что вы не знаете своих инструментов.

Я действительно нервничаю, когда вижу, как он ползает по другим языкам (С#, Python), который, как правило, помечает его!

Ответ 26

Я считаю, что единственным фактором, который когда-либо заставлял бы одно за другим, является то, что цепочка инструментов не предоставляет предупреждений для фиксации присвоений в выражениях. Мое предпочтение как разработчик не имеет значения. Выражение лучше служит для четкого представления бизнес-логики. Если (0 == i) более подходит, чем (i == 0), я выберу его. Если нет, я выберу другую.

Многие константы в выражениях представлены символическими именами. Некоторые руководства по стилю также ограничивают части речи, которые могут использоваться для идентификаторов. Я использую их как руководство, чтобы помочь определить, как это выражение читается. Если результирующее выражение читается свободно как псевдокод, тогда я обычно доволен. Я просто позволяю выражению выражать себя, и если я ошибаюсь, это обычно попадает в рецензирование.

Ответ 27

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

Следовательно, для меня всегда лучше попросить людей использовать (0 == i), как вы никогда не знаете, какой программист делает что. Лучше быть "безопасным, чем жаль"

Ответ 28

if(DialogResult.OK == MessageBox.Show("Message")) ...

Я бы всегда рекомендовал написать сравнение таким образом. Если результат MessageBox.Show( "Сообщение" ) может быть пустым, тогда вы рискуете NPE/NRE, если сравнение будет наоборот.

Математические и логические операции не являются рефлексивными в мире, который включает в себя NULL.