Разве «если (0 == значение)…» не приносит больше вреда, чем пользы? [закрыто]

49

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

Во всяком случае, вот мои аргументы против этого:

  • Это нарушает естественный поток чтения программного кода. Мы, люди, говорим «если значение равно нулю», а не «если значение равно нулю».
  • Современные компиляторы предупреждают вас, когда у вас есть назначение в вашем состоянии, или на самом деле, если ваше условие состоит только из этого назначения, что, да, в любом случае выглядит подозрительно
  • Вы не должны забывать ставить double '=', когда вы сравниваете значения, если вы программист. Вы можете также забыть поставить "!" при проверке неравенства.
mojuba
источник
17
Мне это тоже не безразлично, но это довольно далеко в моем личном списке любимых мозолей.
Адам Кроссленд
7
И программисты иногда пропускают двойное '='. Это простая ошибка, которую легко упустить из виду.
Санге
8
Как это не конструктивно или не реальный вопрос?
TheLQ
7
Это закрыто, поэтому вот мое короткое мнение: как люди могут помнить, чтобы писать, 0 == valueно не помню, чтобы писать ==?? Я имею в виду, что если вы думаете об этом, почему бы не написать это правильно для начала.
Доктор Ганнибал Лектер
3
@muntoo: По словам компиляторов, многие вещи «правильные», я не думаю, что это очень хороший тест.
Доктор Ганнибал Лектер

Ответы:

59

Ах да, "Йода условные" ("Если значение равно нулю, выполнить этот код, вы должны!"). Я всегда указываю всем, кто утверждает, что они «лучше» в таких инструментах, как lint (1). Эта конкретная проблема была решена с конца 70-х годов. Большинство современных языков даже не скомпилируют выражение типа if(x = 10), так как они отказываются приводить результат присваивания логическому значению.

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

TMN
источник
32
+1 для "Йода условных". Я на самом деле LOL на это. :)
Бобби Столы
3
Хотя порядок в порядке, я возражаю против сравнения с нулем вместо простого логического преобразования if(!value).
SF.
1
Так вы считаете назначения внутри условной ошибкой?
4
«Большинство современных языков даже не скомпилируют это» Проблема возникает, когда вы используете язык, который молча приводит к результату присваивания логического значения. Самый популярный язык, о котором я могу подумать, это JavaScript. Вот почему я всегда использую условные выражения yoda даже в Java, так что я не забываю делать это, когда пишу javascript. Я переключаюсь между ними достаточно часто, чтобы это могло (и было) проблемой.
Сэм Хаслер
3
Кто-нибудь знает компилятор, который не будет компилироваться if (0 == x)?
Кристофер Айвс,
56

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

Люди читают слева направо практически на всех языках программирования (и на большинстве естественных языков).

Если я вижу 123 == x, то, как я мысленно разбираю это:

  • 123- И что? неполная информация
  • == - ну, 123 - это 123, зачем это проверять ...
  • x- Хорошо, так вот что нас беспокоит. Только теперь у меня есть контекст.
  • Вернитесь, чтобы пересмотреть 123и почему х сравнивается с этим.

Когда я вижу x == 123умственный анализ:

  • x- Предоставляет контекст, я знаю, что это за условие. Я могу игнорировать все остальное. Основываясь на предыдущем потоке, у меня есть хорошая идея, почему и что будет впереди (и удивлюсь, если это не так).
  • == - Я так и думал.
  • 123 - Ага.

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

Если вы хотите привлечь к себе внимание, лучше поставить значение первым , например if (LAUNCH_NUKES == cmd). Обычно это не намерение.

dbkk
источник
5
Именно так. В естественных языках константа всегда идет последней по той же причине: если красный свет ...
Моджуба
2
@mojuba Правда, это почти универсально. Как ни странно, есть несколько естественных языков, где объект стоит перед субъектом (порядок OVS / OSV), но все они неясны.
ДБКК
1
С другой стороны, некоторые из нас склонны читать символы перед переменной. Они более привлекательны. Поэтому я разберусь, =или ==до, 123или x, и в итоге даже не потрудился перевести код на английский в моей голове.
Иската
Кроме того, большинство компиляторов будут предупреждать, если будет предложено правильно, если только они не используют лишние скобки, поэтому он пытается решить проблему.
Дедупликатор
47

Вредно? Нет, это работает в любом случае.

Плохая практика? Дискуссионный, в лучшем случае. Это простое защитное программирование.

Стоит потерять сон? Неа.

Вонко вменяемый
источник
8
И когда я читаю его, я сразу понимаю код, который является для меня самой важной причиной для обсуждения стиля кодирования. Я полностью согласен, не стоит терять сон.
Джефф Сивер
17

Это в основном фламбайт.

Нет, это не приносит больше вреда, чем пользы. Просто.

Больше слов?

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

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

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

Трудно читать? Вы жалуетесь, что приличный программист должен иметь == аппаратно (что делает все виды ошибочных предположений), но что тот же самый приличный программист не может прочитать 0 == значение ??

Не причиняет вреда, имеет потенциальные выгоды, глупый вопрос, пусть другие делают это, если хотят, и идут дальше.

Murph
источник
6
Я думаю, что 0 == значение выглядит неестественно для тех, кто изучал алгебру, прежде чем они изучали программирование.
Моджуба
4
Это не в этом дело - да, вы правы, это не правильно читает, но в равной степени многое из того, что мы, программисты, пишем, точно не складывается как естественный язык, и вопрос в том, как вы интерпретируете Вы видите
Мерф
4
Браво .. Не говоря уже о том, что из- за того, что он читает неестественно, вы склонны обращать на него более пристальное внимание и, следовательно, улавливать возможные ошибки.
mocj
7
@mocj - Следовательно, мы все должны писать как можно более тупо, чтобы люди, читающие наш код, действительно читали наш код?
Kaz Dragon
6
@mocj - Я ценю это, но твой аргумент состоял в том, что "заикание мозга", когда ты читаешь условную Йоду, - хорошая вещь. Я задаю вопрос, что, если это так, должны ли мы стремиться написать весь код, чтобы вызвать «заикание мозга»? Подлинный вопрос.
Каз Дракон
11

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

как зовут
источник
10

Я никогда не чувствовал, что весь "что если я забуду =?" когда-либо действительно держал большой вес. Да, вы можете сделать опечатку, но мы все делаем опечатки, кажется глупым менять весь ваш стиль кодирования, потому что вы боитесь ошибиться. Почему бы не сделать все ваши переменные и функции строчными, без знаков препинания, потому что вы можете забыть что-то написать с заглавной буквы или забыть подчеркивание в один прекрасный день?

GSto
источник
5
Дело не в этом, дело в том, «вредно ли это», и это не так. Очень слабое раздражение в худшем случае, но не вредное.
Мерф
1
В динамических языках - безусловно, вы можете набрать символ и напрасно тратить свое время на поиски источника ошибки
mojuba
3
При всем уважении, если вы провели позднюю ночь (или две) и обнаружили, что источником (в коде C ++) является = = ==, это будет иметь некоторый вес.
DevSolo
2
@DevSolo: Я думаю, что это должно произойти раз или два в твоей карьере, но не более того
моджуба
9

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

Способ 1:

FILE *fp;

fp = fopen("foo.txt", "w+");
if (fp == NULL) {

Способ 2:

FILE *fp;

if (NULL == (fp = fopen("foo.txt", "w+"))) {

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

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

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

Тим Пост
источник
4
Второй пример заставил меня пойти "а?" Первый намного более читабелен. Отличный пример. :)
Матин Улхак
6

Для меня это просто кондиционирование. Как человек, который выучил (в 90-х годах) C и C ++, я привык к этому и до сих пор использую его, хотя причины этого не оправданы.

Как только вы «обусловлены» смотреть на «постоянную» с левой стороны, это становится второй натурой.

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

Я полностью согласен с ответом Вонко.

DevSolo
источник
5

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

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

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

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

Билл
источник
2
Я думаю, что ключевое слово здесь «другие способы сделать это»;)
Моджуба
в этом случае да, но в некоторых случаях это все еще самый читаемый результат. Единственное, что я хочу сказать, это то, что есть веские причины для этого, кроме как для борьбы с языком или идеальным поведением и тип-о
Билл
Если честно, у меня трудности с условиями Йоды для <= и> =. Знак == - это другое дело, потому что в моей голове я могу просто переключать символы, но в вашем случае я должен помнить, что count () должен быть больше или равен 2, и это довольно раздражает, чтобы получить из знак меньшего или равного.
Алекс
3

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

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

Так что я бы сказал:

if ( 0 <= value )

Но я бы также сказал:

if ( value <= 100 )

Равенство, которое я постараюсь проверить с помощью переменной слева, просто более читабельно.

glenatron
источник
1
Я привык использовать if(y > x)все время. Если только yэто не константа.
Матин Улхак
Раньше я делал это таким образом, но как только у меня появилась идея иметь самые низкие значения слева, я обнаружил, что мой код намного более читабелен с первого взгляда.
Гленатрон