Сделайте большую сделку из == правда?

105

Мой коллега постоянно пишет:

if (someBool == true)

Это доводит меня до стены! Должен ли я сделать большое дело или просто бросить его?

JoelFan
источник
12
Я предпочитаю явное, if (some_flag == true)но неявное if (is_something)или if (has_something). Обратите внимание на имена переменных.
fredoverflow
69
Напомните своему коллеге, что тип someBool == trueтакже является логическим, поэтому по той же логике он должен быть if ((someBool == true) == true).
Майк Сеймур
2
@GSto: Я полагаю, вы это знаете, но в PHP вы можете сделать это, чтобы «привести» что-либо к bool и может быть действительно полезным.
zneak 19.10.10
2
@zneak Или вы могли бы быть более понятным и использовать $var = (bool) some_expression. И в большинстве случаев это даже не имеет значения, поскольку PHP будет выполнять необходимые преобразования динамически.
waiwai933
4
всегда сначала проверяйте константу, если (true == someBool), если вы случайно набрали = вместо == [да, я шучу!]
Стивен А. Лоу

Ответы:

126

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

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

if(IsSomeCondition)

или же

if(hasCondition)

или же

if(somethingExists)

например.

Роберт Харви
источник
Это звучит наиболее верно для меня. Все дело в ясности и искусстве именования, оригинальный синтаксис не так уж и плох, но это правильный путь к лучшему коду.
TJB
2
Обыграй меня! Без надлежащего наименования более краткая эквивалентность не имеет никакого смысла.
Трой Хант
4
Мне пришлось использовать someBool == trueдля унаследованного кода несколько раз для ясности. Но если я пишу с нуля, я if (isSomething)
называю
Я согласен, хотя именование решило бы это, предполагая, что имя было SomeBool, оно может означать что угодно и иметь любой тип (целое число, равное количеству логических значений в массиве, возможно?). Булевы значения нуждаются в каком-то экзистенциальном глаголе, иначе их всегда будет трудно читать самостоятельно.
Морган Херлокер
Я согласен, это все о читабельности. Если переменные названы правильно, вам это не нужно. Если выражение читается лучше с ним, я бы пошел на «== true», также это будет согласованно, если вы используете «== false» вместо (уродливого) «if ​​(! ())».
Ронни Брендель
71

Когда я вижу someBool == true, я не могу не чувствовать, что программист не усвоил идею оценки , что является довольно существенным недостатком.

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

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

Тим Гудман
источник
Я бы не стал так быстро писать это по привычке. Я слышал некоторые действительно потрясающие вещи из уст профессиональных программистов. Вскоре после этого за ним следовал один из гроккеров: «Как это вообще сработало?»
дэш-том-бэнг
12
Согласитесь от всего сердца по поводу оценки. Иногда я задавался вопросом: «Где это останавливается?» if ((((x == true) == true) == true)! = false) // и т. д.
yawmark 19.10.10
1
Иногда я писал бы if (c == true) return true; else return false;, но в 99% случаев (1% есть, поскольку я никогда не могу быть уверен, что не пропустил некоторые из них), я сразу замечу и заменю все это return c. Я ожидаю, что большинство компетентных программистов должны сделать что-то подобное, если они выработали привычку в начале своей карьеры. Чего бы я не ожидал, так это ответа ВТФ.
Ли Райан
1
О, мальчик, искусство мышления. Я буквально сталкивался с этим в нашей базе кода на прошлой неделе. if (!someCondition) { someCondition = false; }Я видел некоторые (много, много) избыточностей, а также некоторые невозможности в нашем коде, но этот был настолько простым, но настолько отягчающим, чтобы думать, что кто-то действительно написал это. Несколько раз, даже.
Энтони Пеграм
1
Просто отметьте, что я видел несколько случаев, if(x) x=true;которые НЕ были излишними, а скорее эквивалентными x=!!x;(нормализация x к 0/1)
jkerian 20.10.10
58

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

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

if (someBool==true)&&(true==true) {}

ИМ: Зачем нам это делать? Вторая половина этого утверждения является избыточной, она всегда будет иметь значение true.

Вы: Джорджем, вы правы. Дурак я. Тогда давайте просто перейдем к версии без избыточности. Как насчет?

if (someBool) {}
JohnFx
источник
6
Да, согласился. Это глупо, но вы должны выбирать свои бои, и этот код действительно делает то, что делает ваш коллега. Упомяните это в не- "Что, черт возьми, не так с тобой ?!" таким образом, тогда бросьте это. Хотя, если они начнут тянуть дерьмо, как «if (someBool! = True)» или «if (! SomeBool == true)» или другие подобные свертки, это может быть бой, достойный выбора…
BlairHippo
3
Чем (someBool == false) хуже, чем если (someBool == true)?
FinnNk 18.10.10
5
true=trueне компилируется, вы не можете назначить до true;-)
fredoverflow
1
Я привык к if(somebool == false)или !=, но всегда против ложного и не правда. Я считаю это излишним, но поскольку стандарт кодирования настаивает на том, что if()вызов функции напоминает пробел между скобками, это помогает мне прочитать его. Сам по себе bool - это bool, но if (somePointer)он не летает; Я предпочитаю, if (somePointer != NULL)так как указатель не бул.
дэш-том-бэнг
5
Речь идет о читабельности, а не нелогичности или (микро) избыточности
Ронни Брендель
45

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

GrandmasterB
источник
5
Ну что ж, хорошо стремиться к совершенству, но наверняка есть рыба побольше
TJB
3
Я думаю, что вы говорите это о каждой проблеме, которая заслуживает обсуждения.
Дэйв Ван ден Эйнд
2
Это потенциально указывает на гораздо большие проблемы. Маленькое коричневое пятно на потолке в вашем гараже может показаться не таким уж серьезным, но это может означать, что у вас большая утечка воды.
Джош
42

Вы должны определенно остановить эту вредную привычку. Осторожно ...

Легко забыть написать двойные знаки равенства, превращая код в:

if (someBool = true)

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

Guffa
источник
6
Это не актуальный аргумент. Если вы работаете на таком языке, вы можете просто переместить истину на другую сторону. Вопрос в том, стоит ли вообще включать истину.
Cam
8
@Cam: Соскучились по тебе. Заднюю логику я не предлагаю.
Guffa
15
@Cam - Он дает реальный пример того, когда это может быть проблемой. Я бы сказал, что это очень актуально.
ChaosPandion
1
@ Гуффа Кэм очень права. Это не причина прекращать использование == (anyType) в блоках if.
Ронни Брендель
2
@Ronny: Нет, это не может произойти с любым типом (если язык фактически не позволяет использовать любой тип как условие) Утверждение if (answer = 42) {}просто не компилируется, потому что выражение не является логическим.
Guffa
21

Я согласен с вами, но я собираюсь сыграть адвоката дьявола здесь:


В зависимости от языка и имени переменной подходит x == true:

Рассмотрим следующую ситуацию в языке со статической типизацией и приведением типов для целочисленных типов:

if (actionsAllowed){
    //do actions, since they are allowed
    //...
}

Кто-то, читающий этот раздел кода, может не сразу понять, что actionsAllowed является булевой переменной - это также может быть целое число, представляющее количество разрешенных действий. Таким образом, добавив == true, становится ясно, что x является логическим значением, а не целым числом, приведенным к логическому:

if (actionsAllowed == true){
    //do actions, since they are allowed
    //...
}
кулачок
источник
13
удобочитаемость == GoodThing
Muad'Dib
5
если ((удобочитаемость == GoodThing) == правда) ...
JoelFan
1
bool isGoodThing = readibility? true: (codingStandards? true: (internalizationOfConcept? true: false));
johnc 19.10.10
17
Так что переименуйте переменную actionsAreAllowed.
Грэм Перроу
9
Написав, if (x) { ...вы уже утверждаете, что xэто логическое значение или оно может быть преобразовано в логическое значение. То, что вы называете, не имеет значения.
Дэниел Эрвикер
15

А как насчет бул?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 
Стив Велленс
источник
if (MyFlag.Value)
johnc 19.10.10
1
Не все языки имеют допускаемые значения bools, и многие из тех, кто это делает, примут вашу вторую конструкцию.
2010 г.
1
@johnc: «if (MyFlag.Value)» может на самом деле не делать то, что вы хотите, поскольку он может выдать исключение, если MyFlag имеет значение null (которое можно проверить, проверив MyFlag.HasValue).
Людовик Чабант
4
Это моя любимая мозоль с обнуляемыми бурами :)
Джаррод Диксон
3
BOOL? isValid = null; if (isValid ?? false);
Сколима 19.10.10
11

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

При этом я не вижу проблем с добавлением == trueк условному выражению. На самом деле, я имею обыкновение использовать == falseв отличие от ведущего восклицательного знака при тестировании на негативные условия. Я думаю, что это более читабельно.

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

Casey
источник
1
В зависимости от вашего языка someValue может не обязательно быть эквивалентом true, даже если оно имеет значение true. Например, (9 == True)оценивается как ложное в Python, и я представляю себе подобное в C ++.
дэш-том-бэнг
кодовые регионы и подчеркивания заставляют меня хотеть бить людей по лицу.
MGOwen
11

Ack. Я тот парень. Стыд, позор. Это то, как я учился, и то, как я «автоформатировал» в своей голове. Единственный раз, когда я использую предпочтительный синтаксис Джоэла, это когда переменная bool имеет префикс глагола типа «есть». Мне нужен глагол, будь то «есть», «может», «сделал», или же мне нужен ==, чтобы обеспечить глагол «равно». Я мог бы никогда не сломать эту привычку, поэтому я пойму, если вы не скажете «привет» мне на улице.

Скотт Флетчер
источник
7
Это не плохо. Код, который читается как настоящий текст, намного лучше, чем неявный foo. Сохраняйте эту привычку ради читабельности.
Ронни Брендель
11

напомни мне о "булевом коде безумия", вот так

if(someBool == true)
   otherBool = false;
else
   otherBool = true

Вместо:

 otherBool = !someBool
Марсело де Агиар
источник
Забавно, я должен был поддерживать систему, в которой все было засорено. Это сводило меня с ума.
Tjaart
8

Лично мне сильно не нравится, когда я говорю «нет» в языках, основанных на Си. Этот маленький восклицательный знак слишком легко упустить из виду.

Поэтому я выписываю это полностью:

if (someCondition == false) {

Прочитав некоторое время, я тоже хочу симметрию с

if (someCondition == true) {

Так что считайте это артефактом использования C !вместо not.

user1249
источник
3
C ++ на самом деле имеет в notоператора, а так же C (как только вы включите стандартный заголовок <iso646.h>). Если вы не хотите (или не можете) использовать этот заголовок (или , если вы застряли с Java или C #), я предлагаю положить пробел после восклицательного знака: if (! condition). Это делает его несколько более заметным.
Конрад Рудольф
1
Я делаю Java. notэто не вариант.
6

Это зависит от языка, но обычно это плохая идея ...

В Си никогда не делай этого. Слишком легко найти ситуацию, когда проверяемое вами значение не является ложным (ненулевым), но также не равно единственному значению, определенному как «истина».

В Ruby, делайте это только в том случае, если вы абсолютно уверены, что хотите потерпеть неудачу во всем, кроме Boolean true.

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

оборота AShelly
источник
На самом деле, в языках, где оператор присваивания возвращает значение ... как C ++ ... if (b == true) {не просто избыточно. Это также немного рискованно, потому что вы можете быть случайно назначены trueна b.
Стивен С
4
Это не просто избыточно в C ++, это опасно. Если вы пишете if (b == true), а bне как бул, преобразования типов идут неправильно. boolЯвляется составным типом , который , как правило , повышен до соответствующего интегрального типа со значением 1. Если вы пишете, скажем, int b(2); if (b == true)то trueстановится intсо значением 1 для целей сравнения, а не bпринуждают к типу bool, который даст правильный результат.
Дэвид Торнли
@DavidThornley, включите предупреждения в вашем компиляторе. Рассматривать предупреждения как ошибки - лучший способ защиты, а не избегать ==.
Abyx
5

Ты думаешь это плохо? Как насчет:

if(someCondition) {
  return true;
} else {
  return false;
}
Сверре Раббелье
источник
2
Мальчик, сколько раз я видел это. Это хороший пример для такого инструмента, как ReSharper.
Работа
Да, если вы нанимаете комов, то покупайте ReSharper.
Кирк Бродхерст
4

я предпочитаю

if (bVal)

или же

if (!bVal)

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

оборота грокус
источник
4
За любовь ко всему святому, если это не так if (!bNotVal) или if (bNotVal)даже вообще. Тьфу негативы в именах делает все труднее читать.
дэш-том-бэнг
2
Я знал разработчика, который будет bool isNotConnected; if (isNotConnected == true) ... гадость
johnc 19.10.10
4

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

его

if (true == someBool) {

}

если он когда-нибудь забудет = у него большие проблемы с его стилем письма.

Отображаемое имя
источник
3

Как насчет

if (x == "true")

ПОЧЕМУ ЭТО СТРОКА ?!

atfergs
источник
Я работаю над некоторым устаревшим php-кодом, и иногда я нахожу что-то вроде if(preg_match('/title/', implode($_POST))){. PHP, достаточно сказал, мне нужно найти лучшую работу.
Кейо
4
да, я также вижу, если (x == "1"), но это обычно делает плохой дизайн БД.
atfergs 19.10.10
Я использовал аналогичные конструкции, когда xисходил из пользовательского ввода (например, файла конфигурации или веб-службы). Тем не менее, я обычно допускаю другие истинные ценности, так что в конечном итоге это if x.lower().strip() in ["true", "yes", "on", "1"]
выглядит
3

На самом деле, если он может быть обнуляемым, необходимо проверить x == true. :)

Мэтт Шерман
источник
3

Я пишу такой код!

Вот почему:

«if bla == true» читается как предложение, а «if bla» - не во многих случаях. Это просто звучит неправильно, когда ЧИТАЕТ реальный код.

Также компилятор предупреждает о присваиваниях в блоках if, поэтому при использовании == true нет никакой опасности. (путая это с =)

Также парни, которые не пишут "== true", используют это "! ()" Для "== false"? Я нахожу это действительно безобразным. И если вы используете «== false», то очень просто использовать «== true» вместо двух разных способов проверки истины.

Ронни Брендель
источник
3
Вы говорите «если бла» не читается как предложение ... это означает, что ваша переменная не имеет правильного имени ... что не так с этим: if (userHasRights) doSomething ()
JoelFan
"во многих случаях". Да ты прав. Переименование тоже хорошо. С помощью «if (QWidget :: acceptDrops () == true)» у вас нет возможности переименовать. возможно, было бы хорошо, чтобы назвать его doAcceptDrops () ... Это слишком много хлопот (и это невозможно согласовать, используя это правило пропуска в любом API), поэтому совместим с другими "== какими-либо" -ifs, Я настоятельно рекомендую не опускать его, чтобы он не "выглядел" по-другому, и поэтому выглядел согласованно.
Ронни Брендель
3

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

cdkMoose
источник
2

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

FinnNk
источник
3
Кроме того, если это входит в стандарты кодирования команды, вам действительно нужно переоценить стандарты, чтобы избавиться от подобных мелочей.
JohnFx 18.10.10
Согласовано! Хотя на всякий случай ...
FinnNk 18.10.10
2

Хотя я согласен как разработчик C #, я не могу сказать, что это всегда так. Например, в Javascript === будет выполнять слияние типов. Итак, предполагая, что var x = 3, тогда:

if(x) --> true

пока

if (x === true) --> false

Я думаю, это отличается от ==, поскольку даже в JS я бы не использовал if (x == true), а просто подумал.

Этот вид затрагивает другой момент, который возник в моем офисе:

bool b = false;

В C #, bool b; было бы достаточно и инициировало бы b в ложь . Тем не менее, более четко написать вышеприведенную строку и в любом случае должен быть разорван компилятором во время оптимизации.

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

statichippo
источник
bool b;только инициализируется как false когда bполе. Вы должны инициализировать локальные переменные явно.
Мэтью Флэшен
+1 согласился. То же самое касается и других (скриптовых) языков. Вы должны быть явными, если хотите проверить логическое значение trueили просто «true». Например, то есть любая непустая строка рассматривается, == trueно не === trueна некоторых языках.
Мартин Уикман
2

Ах да, но что, если переменная может быть обнуляемой? (BOOL?)

Некоторые языки (C #) потребуют и приведут или сравнят с 'true'.

bool? isAccepted = true;

if((bool)isAccepted)
{...}

if(isAccepted == true)
{...}
Джаред Г
источник
2

Молодые знают правила, а старые знают исключения;)

В последнем C#случае, если вы имеете дело с null-able bool, то вам необходимо:

bool? x = null;
bool? y = true;
bool? z = false;
if (x == true || y == true || z == true) {
    // That was the only way that is reasonably readable that I know of
    // to accomplish this expression.
}

Если tristate не является проблемой, то обычно не должно быть причины сравнивать что-либо с true/ True. Тем не менее, в Pythonнекоторых других языках, таких как C/C++вы, вы можете выполнять выражения, ifотличные от bool. Эти языки имеют уникальные правила для интерпретации целых чисел, указателей, списков и т. Д. Как истинных или ложных. Иногда ты этого не хочешь. Например, в этом фрагменте Python:

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

Здесь zдолжно быть True, но z2должно быть False. Теперь Clojureязык подходит к этому еще одним способом - там andфункция не обязательно оценивает a bool, но ifможет справиться с этим.

Независимо от языка, каждый раз, когда вы сравниваете что-то с Trueили False, это, вероятно, стоит комментировать.

работа
источник
Первая проблема проистекает из ложной предпосылки IMO с использованием ужасных имен переменных. Пусть х, у, г были названы notExceptButHasX, exceptNotButIsntY, doNotUnlessIsExceptZ? Как это делает для удобочитаемости в вашей проблеме? Если x, y, z были названы что-то вроде «isEnabled», «isEffective», «hasProperty», то ваше утверждение становится isEnabled || isEffective || hasPropertyгораздо более читабельным, чем сравнение с trueили false.
Томас
1

Такое кодирование и раньше бы меня терло. Хотя ваш пример идентификатора называется «someBool», использование этого стиля кодирования непреднамеренно для переменной, которая не гарантированно является логическим, может иметь непреднамеренное поведение. Если значение «someBool» не совсем «истина» или «ложь», результат будет ложным.

В прошлом году я столкнулся с очень тонкой ошибкой, вызванной таким стилем кодирования, который трудно было идентифицировать, потому что глаза закрывают глаза на такие конструкции. Вы подумаете: «Как это может быть неправильно?» То же самое относится и к таким понятным выражениям, как «(var)» или «(! Var)», что вы читаете или кодируете их, не проверяя их поведение.

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

  1. Все выражения должны быть заключены в скобки в соответствии с их намерением.
  2. Все булевы тесты должны быть выражены отрицательно, например «suchBool! = False».

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

Huperniketes
источник
1
Наличие некоторого someBool, способного быть чем-то отличным от TRUE / FALSE, является плохой практикой кодирования.
AttackingHobo
@AttackingHobo, это одна из ловушек отсутствия булевых типов в языке и / или использования класса для обеспечения требуемого поведения.
Гуперникетес
1

Пришлось все время использовать это в ActionScript 2 (по общему признанию, теперь мертвый язык), потому что:

var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();

// this is slightly ambiguous
if(something)
{
}

// because if you allow undefined you might actually mean
if(false != something)
{
}

// which can mean something different than
if(true == something)
{
}

// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}

Так что почти всегда лучше быть конкретным.

bburbank
источник
1

Я согласен. Это избыточная конструкция, особенно в строго типизированных языках.

Чтобы добавить еще одно неправильное использование логических выражений, я встречал такую ​​конструкцию несколько раз в Javascript (особенно в некоторых спагетти-подобных функциях монстров, как в 100+ строках):

//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example 
flag=$("mycheckbox").selected;
//...

//and at the moment of use it:
if(flag!=true) {
   //code to execute when the checkbox is unchecked
}

Кажется, что из-за отсутствия строгого определения типа в этом языке, некоторые программисты предпочитают не возиться со false|undefinedзначениями.

Томас Наррос
источник
1

У меня есть коллега, у которого будет такой код:

if(something == true)

И затем, для какого-то теста / отладки, он захочет не вызывать этот блок, поэтому он изменит его на:

if(something == true && false)

И тогда иногда он изменит это на:

if(false)

Хуже всего то, что этот тип отладки иногда теряет меня и очень плох для чтения другими разработчиками!

ingh.am
источник
0

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

(Это сказанное, это также действительно раздражало бы меня - но вероятно недостаточно для того, чтобы сделать из этого большое дело).

driis
источник
0

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

санге
источник
0

как насчет:

int j = 1;
for (int i=1; i>=j; i++) ...

Да, я видел это.

Дейв
источник