Мой коллега постоянно пишет:
if (someBool == true)
Это доводит меня до стены! Должен ли я сделать большое дело или просто бросить его?
Мой коллега постоянно пишет:
if (someBool == true)
Это доводит меня до стены! Должен ли я сделать большое дело или просто бросить его?
if (some_flag == true)
но неявноеif (is_something)
илиif (has_something)
. Обратите внимание на имена переменных.someBool == true
также является логическим, поэтому по той же логике он должен бытьif ((someBool == true) == true)
.$var = (bool) some_expression
. И в большинстве случаев это даже не имеет значения, поскольку PHP будет выполнять необходимые преобразования динамически.Ответы:
Это всего лишь избыточный код, а не жизнь или смерть. Тем не мение....
Если это происходит много, это может быть проблемой с тем
someBool
, как называется. Хорошее имя может иметь большое значение для устранения необходимости==true
или же
или же
например.
источник
someBool == true
для унаследованного кода несколько раз для ясности. Но если я пишу с нуля, яif (isSomething)
Когда я вижу
someBool == true
, я не могу не чувствовать, что программист не усвоил идею оценки , что является довольно существенным недостатком.Тем не менее, моя точка зрения искажена, потому что я провел несколько лет в колледже, обучая программированию детей, которые часто писали такие выражения, потому что они по-настоящему не освоили умственное упражнение по оценке выражения. Как только они ухватились за концепцию, избыточность стала очевидной.
Для компетентного профессионального программиста это, вероятно, не тот случай. Вероятно, это просто плохая привычка, которую они разработали в первые годы программирования и никогда не испытывали шока. Но это все равно немного напугало бы меня, если бы я впервые увидел, что кто-то сделал в интервью.
источник
if (c == true) return true; else return false;
, но в 99% случаев (1% есть, поскольку я никогда не могу быть уверен, что не пропустил некоторые из них), я сразу замечу и заменю все этоreturn c
. Я ожидаю, что большинство компетентных программистов должны сделать что-то подобное, если они выработали привычку в начале своей карьеры. Чего бы я не ожидал, так это ответа ВТФ.if (!someCondition) { someCondition = false; }
Я видел некоторые (много, много) избыточностей, а также некоторые невозможности в нашем коде, но этот был настолько простым, но настолько отягчающим, чтобы думать, что кто-то действительно написал это. Несколько раз, даже.if(x) x=true;
которые НЕ были излишними, а скорее эквивалентнымиx=!!x;
(нормализация x к 0/1)Это тоже сводит меня с ума, но я бы сказал, что упомяну им избыточность конструктивно, а затем урону, даже если они не согласятся.
В качестве альтернативы вы можете попробовать этот подход:
Вы: Можете ли вы начать использовать следующее соглашение кода для оценки логических значений?
ИМ: Зачем нам это делать? Вторая половина этого утверждения является избыточной, она всегда будет иметь значение true.
Вы: Джорджем, вы правы. Дурак я. Тогда давайте просто перейдем к версии без избыточности. Как насчет?
источник
true=true
не компилируется, вы не можете назначить доtrue
;-)if(somebool == false)
или!=
, но всегда против ложного и не правда. Я считаю это излишним, но поскольку стандарт кодирования настаивает на том, чтоif()
вызов функции напоминает пробел между скобками, это помогает мне прочитать его. Сам по себе bool - это bool, ноif (somePointer)
он не летает; Я предпочитаю,if (somePointer != NULL)
так как указатель не бул.Я думаю, что, если что-то настолько тривиальное, является вашей самой большой проблемой с вашими коллегами, вы должны считать себя довольно удачливым.
источник
Вы должны определенно остановить эту вредную привычку. Осторожно ...
Легко забыть написать двойные знаки равенства, превращая код в:
Например, в C # это будет выдавать только предупреждение, а не ошибку. Поэтому, если вы не воспримете предупреждения как ошибки, код будет выполняться, установите для переменной значение true и всегда вводите условие.
источник
if (answer = 42) {}
просто не компилируется, потому что выражение не является логическим.Я согласен с вами, но я собираюсь сыграть адвоката дьявола здесь:
В зависимости от языка и имени переменной подходит x == true:
Рассмотрим следующую ситуацию в языке со статической типизацией и приведением типов для целочисленных типов:
Кто-то, читающий этот раздел кода, может не сразу понять, что actionsAllowed является булевой переменной - это также может быть целое число, представляющее количество разрешенных действий. Таким образом, добавив == true, становится ясно, что x является логическим значением, а не целым числом, приведенным к логическому:
источник
actionsAreAllowed
.if (x) { ...
вы уже утверждаете, чтоx
это логическое значение или оно может быть преобразовано в логическое значение. То, что вы называете, не имеет значения.А как насчет бул?
источник
Как правило, вы не хотите придавать большого значения соглашениям о кодировании, если только это соглашение каким-то образом не мешает проекту. Я видел много горячих споров по таким маленьким вещам, как регионы кода и первые подчеркивания.
При этом я не вижу проблем с добавлением
== true
к условному выражению. На самом деле, я имею обыкновение использовать== false
в отличие от ведущего восклицательного знака при тестировании на негативные условия. Я думаю, что это более читабельно.Если существует установленное соглашение, я говорю: следуйте ему, если нет причин для изменения. Тем не менее, это не стоит поднимать вонючий вопрос.
источник
(9 == True)
оценивается как ложное в Python, и я представляю себе подобное в C ++.Ack. Я тот парень. Стыд, позор. Это то, как я учился, и то, как я «автоформатировал» в своей голове. Единственный раз, когда я использую предпочтительный синтаксис Джоэла, это когда переменная bool имеет префикс глагола типа «есть». Мне нужен глагол, будь то «есть», «может», «сделал», или же мне нужен ==, чтобы обеспечить глагол «равно». Я мог бы никогда не сломать эту привычку, поэтому я пойму, если вы не скажете «привет» мне на улице.
источник
напомни мне о "булевом коде безумия", вот так
Вместо:
источник
Лично мне сильно не нравится, когда я говорю «нет» в языках, основанных на Си. Этот маленький восклицательный знак слишком легко упустить из виду.
Поэтому я выписываю это полностью:
Прочитав некоторое время, я тоже хочу симметрию с
Так что считайте это артефактом использования C
!
вместоnot
.источник
not
оператора, а так же C (как только вы включите стандартный заголовок<iso646.h>
). Если вы не хотите (или не можете) использовать этот заголовок (или , если вы застряли с Java или C #), я предлагаю положить пробел после восклицательного знака:if (! condition)
. Это делает его несколько более заметным.not
это не вариант.Это зависит от языка, но обычно это плохая идея ...
В Си никогда не делай этого. Слишком легко найти ситуацию, когда проверяемое вами значение не является ложным (ненулевым), но также не равно единственному значению, определенному как «истина».
В Ruby, делайте это только в том случае, если вы абсолютно уверены, что хотите потерпеть неудачу во всем, кроме Boolean true.
В C ++ и других статических языках с типом bool он избыточен и может привести к ошибкам программирования при неправильном вводе
=
вместо==
или ошибкам продвижения, как указано в комментариях.источник
if (b == true) {
не просто избыточно. Это также немного рискованно, потому что вы можете быть случайно назначеныtrue
наb
.if (b == true)
, аb
не как бул, преобразования типов идут неправильно.bool
Является составным типом , который , как правило , повышен до соответствующего интегрального типа со значением 1. Если вы пишете, скажем,int b(2); if (b == true)
тоtrue
становитсяint
со значением 1 для целей сравнения, а неb
принуждают к типуbool
, который даст правильный результат.==
.Ты думаешь это плохо? Как насчет:
источник
я предпочитаю
или же
тоже, но я боюсь, что поднятие этого вопроса разозлит людей, поэтому я советую забыть об этом. Сожалею!
источник
if (!bNotVal)
илиif (bNotVal)
даже вообще. Тьфу негативы в именах делает все труднее читать.Вы должны сказать ему, что он делает это неправильно.
его
if (true == someBool) {
}
если он когда-нибудь забудет = у него большие проблемы с его стилем письма.
источник
Как насчет
ПОЧЕМУ ЭТО СТРОКА ?!
источник
if(preg_match('/title/', implode($_POST))){
. PHP, достаточно сказал, мне нужно найти лучшую работу.x
исходил из пользовательского ввода (например, файла конфигурации или веб-службы). Тем не менее, я обычно допускаю другие истинные ценности, так что в конечном итоге этоif x.lower().strip() in ["true", "yes", "on", "1"]
На самом деле, если он может быть обнуляемым, необходимо проверить x == true. :)
источник
Я пишу такой код!
Вот почему:
«if bla == true» читается как предложение, а «if bla» - не во многих случаях. Это просто звучит неправильно, когда ЧИТАЕТ реальный код.
Также компилятор предупреждает о присваиваниях в блоках if, поэтому при использовании == true нет никакой опасности. (путая это с =)
Также парни, которые не пишут "== true", используют это "! ()" Для "== false"? Я нахожу это действительно безобразным. И если вы используете «== false», то очень просто использовать «== true» вместо двух разных способов проверки истины.
источник
Помните, что вы работаете как часть команды, поэтому вам нужно решить все это вместе. «Приятно играть с другими» остается важной чертой личности даже после начальной школы :)
источник
Обычно пропускает '== true', но вряд ли стоит даже минуту, чтобы обсудить его, если вы не включите его в стандарты кодирования вашей команды.
источник
Хотя я согласен как разработчик C #, я не могу сказать, что это всегда так. Например, в Javascript === будет выполнять слияние типов. Итак, предполагая, что var x = 3, тогда:
пока
Я думаю, это отличается от ==, поскольку даже в JS я бы не использовал if (x == true), а просто подумал.
Этот вид затрагивает другой момент, который возник в моем офисе:
В C #, bool b; было бы достаточно и инициировало бы b в ложь . Тем не менее, более четко написать вышеприведенную строку и в любом случае должен быть разорван компилятором во время оптимизации.
Поэтому я думаю, что моя точка зрения состоит в том, что не всегда так очевидно, что является и не является хорошей практикой, и многое из этого сводится к предпочтениям, а также к особенностям / причудам языка.
источник
bool b;
только инициализируется как false когдаb
поле. Вы должны инициализировать локальные переменные явно.true
или просто «true». Например, то есть любая непустая строка рассматривается,== true
но не=== true
на некоторых языках.Ах да, но что, если переменная может быть обнуляемой? (BOOL?)
Некоторые языки (C #) потребуют и приведут или сравнят с 'true'.
источник
Молодые знают правила, а старые знают исключения;)
В последнем
C#
случае, если вы имеете дело сnull-able bool
, то вам необходимо:Если tristate не является проблемой, то обычно не должно быть причины сравнивать что-либо с
true
/True
. Тем не менее, вPython
некоторых других языках, таких какC/C++
вы, вы можете выполнять выражения,if
отличные от bool. Эти языки имеют уникальные правила для интерпретации целых чисел, указателей, списков и т. Д. Как истинных или ложных. Иногда ты этого не хочешь. Например, в этом фрагменте Python:Здесь
z
должно бытьTrue
, ноz2
должно бытьFalse
. ТеперьClojure
язык подходит к этому еще одним способом - тамand
функция не обязательно оценивает abool
, ноif
может справиться с этим.Независимо от языка, каждый раз, когда вы сравниваете что-то с
True
илиFalse
, это, вероятно, стоит комментировать.источник
notExceptButHasX
,exceptNotButIsntY
,doNotUnlessIsExceptZ
? Как это делает для удобочитаемости в вашей проблеме? Если x, y, z были названы что-то вроде «isEnabled», «isEffective», «hasProperty», то ваше утверждение становитсяisEnabled || isEffective || hasProperty
гораздо более читабельным, чем сравнение сtrue
илиfalse
.Такое кодирование и раньше бы меня терло. Хотя ваш пример идентификатора называется «someBool», использование этого стиля кодирования непреднамеренно для переменной, которая не гарантированно является логическим, может иметь непреднамеренное поведение. Если значение «someBool» не совсем «истина» или «ложь», результат будет ложным.
В прошлом году я столкнулся с очень тонкой ошибкой, вызванной таким стилем кодирования, который трудно было идентифицировать, потому что глаза закрывают глаза на такие конструкции. Вы подумаете: «Как это может быть неправильно?» То же самое относится и к таким понятным выражениям, как «(var)» или «(! Var)», что вы читаете или кодируете их, не проверяя их поведение.
Итак, я ввел пару стандартов кодирования, чтобы уменьшить существование таких ошибок в базе кода и вероятность того, что такие тонкие ошибки будут случайно возникать в будущем.
Очистив код, не соответствующий новому стилю, я выявил и исправил еще несколько примеров таких тонких ошибок.
источник
Пришлось все время использовать это в ActionScript 2 (по общему признанию, теперь мертвый язык), потому что:
Так что почти всегда лучше быть конкретным.
источник
Я согласен. Это избыточная конструкция, особенно в строго типизированных языках.
Чтобы добавить еще одно неправильное использование логических выражений, я встречал такую конструкцию несколько раз в Javascript (особенно в некоторых спагетти-подобных функциях монстров, как в 100+ строках):
Кажется, что из-за отсутствия строгого определения типа в этом языке, некоторые программисты предпочитают не возиться со
false|undefined
значениями.источник
У меня есть коллега, у которого будет такой код:
И затем, для какого-то теста / отладки, он захочет не вызывать этот блок, поэтому он изменит его на:
И тогда иногда он изменит это на:
Хуже всего то, что этот тип отладки иногда теряет меня и очень плох для чтения другими разработчиками!
источник
Я бы сказал, что последовательность в корне кодов. Таким образом, вы должны использовать стиль, который в основном используется в вашей организации. Постарайтесь сделать ваш любимый стиль частью официального руководства по кодированию. Если это уже указано в руководстве, просто следуйте ему.
(Это сказанное, это также действительно раздражало бы меня - но вероятно недостаточно для того, чтобы сделать из этого большое дело).
источник
Я предпочитаю не ставить дополнительные == true, но иногда я случайно включаю их и не замечаю. Человек, возможно, не заметил и случайно разместил их. Я перечитываю свой код и иногда замечаю, что я добавил лишний == true, поэтому я удаляю это == true. Иногда я этого не замечаю и с радостью приветствую того, что кто-то сказал мне, что я разместил это излишне.
источник
как насчет:
Да, я видел это.
источник