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

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

Я бы абсолютно не стал просить программиста повзрослеть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В C# не имеет значения, помещаете ли вы переменную первой или последней, потому что присваивания не оцениваются как bool (или что-то, что может быть преобразовано в bool), поэтому компилятор перехватывает любые ошибки, такие как «if (i = 0) CompleteCompanyData.Delete ( ) "

Так что, по крайней мере, в мире C# это вопрос стиля, а не отчаяния. А помещать переменную последней неестественно для англоговорящих. Поэтому для более удобочитаемого кода сначала переменная.

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

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

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

if (i = 0) {
}

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

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

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

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

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

В Java и C# опечатка «присвоение вместо сравнения» заканчивается недопустимым кодом, за исключением очень редкой ситуации, когда вы сравниваете два логических значения.

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

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

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

«А?», - думаете вы.

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

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

мне кажется ошибочным. Суть уловки - избежать случайного назначения чего-либо.

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

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

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

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

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

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

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

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

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

:1 -> x

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

:if (1=x)

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

1. (0 == я)

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

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

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

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

Третий вариант - полностью запретить присваивание внутри условных выражений:

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

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

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

-Адам

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

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

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

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

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

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

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

Раньше я был убежден, что более читаемый вариант (i == 0) - лучший вариант.

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

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

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

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

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

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

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

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

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

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

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

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

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