То, как проверить на, равняется? (0 == i) или (я == 0) [закрытый]

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

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

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

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

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

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

:1 -> x

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

:if(1=x)

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

Я всегда иду со вторым методом. В C#, пишущий

if (i = 0) {
}

результаты в ошибке компилятора (не может преобразовать интервал в bool) так или иначе, так, чтобы Вы могли сделать ошибку, не на самом деле проблема. При тестировании bool компилятор все еще выпускает предупреждение, и Вы не должны сравнивать bool с TRUE или FALSE. Теперь Вы знаете почему.

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

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

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

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

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

я редко вижу много преимущества от удобочитаемости POV.

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

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

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

, если getDayOfWeek () возвращает константу (и поэтому не lvalue) так или иначе!

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

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

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

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

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

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

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

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

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

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

с тех пор, getDynamicString () мог бы возвратить пустой указатель. чтобы быть большим количеством conststent, запишите 0 == я

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

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

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

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

-Adam

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

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

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

я абсолютно не попросил бы, чтобы программист рос все же.

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

"А?", Вы думаете.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

я - также намного более крупный поклонник Java "Постоянная строка" .equals (dynamicString), никакие исключения нулевого указателя хорошая вещь.

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

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

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

, В частности, в Java я нахожу полезным сделать:

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

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

Не имеет значения в C# при помещении переменной сначала или в последний раз потому что присвоения не оценивают к bool (или что-то castable к bool), таким образом, компилятор фиксирует любые ошибки как "если (я = 0) EntireCompanyData. Удалите ()"

Так, в мире C#, по крайней мере, это - вопрос стиля, а не отчаяния. И помещение переменной в последний раз является неестественным англоговорящим. Поэтому для большего количества читаемого кода, переменная сначала.

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

1. (0 == i)

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

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

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

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