Комментарий к этому вопросу: проверка, возвращает ли метод значение false: присваивать результат временной переменной или помещать вызов метода непосредственно в условное выражение? говорит, что вы должны использовать !boolean
вместо того, чтобы boolean == false
при тестировании условий. Почему? Для меня boolean == false
это намного более естественно на английском языке и более явно. Я извиняюсь, если это просто вопрос стиля, но мне было интересно, была ли какая-то другая причина для этого предпочтения !boolean
?
language-agnostic
coding-style
boolean
оборота
источник
источник
boolean == true
: это не имеет смысла. Выражения внутриif
операторов - это просто выражения. Если что-то уже вычисляется в булево выражение, зачем вам добавлять проверку, чтобы заставить это оценить?!boolean_variable
так делают большинство программистов на С, я согласен.boolean != true
?Ответы:
Когда я вижу такую строку
if (!lateForMeeting())
, я читаю это как «Если не опаздывает на встречу» , что довольно просто понять, в отличие от того,if (lateForMeeting() == false)
что я читал бы как «Если факт, что я опаздываю на встречу, является ложным " .Они идентичны по смыслу, но первое ближе к тому, как будет строиться эквивалентное английское предложение.
источник
if not late_for_meeting
:)unless late_for_meeting
done()
. Двойные негативы плохие.Написание
== false
и== true
является излишним. Это также может привести к произвольным крайностям. Если вы начнете писатьТогда почему бы и нет
Или почему нет
Мораль этой истории в том, что если
condition
это логическое выражение, то вам не нужно добавлять== false
; для этого и нужен оператор!
;)источник
== false
НЕ избыточен, просто более многословен, чем!
. OTOH,== true
это избыточно.(exp1 != exp2)
против((exp1 == exp2) == false)
. Следует признать, что это надуманные сценарии, но, тем не менее, вы почти никогда не должны писать явные сравнения с истиной или ложью. Точно так же, как вы должны использовать оператор!=
, так что вы должны использовать!
.!
.bool_expression == bool_literal
,== ...
это избыточно. Независимо от того, проверяете ли вы на истинность или ложь, не имеет значения Это просто изменение порядка последовательных / альтернативных блоков. Примеры Андреса прекрасно иллюстрируют этот момент. Большинство современных компиляторов оптимизируют избыточность, но она все еще избыточна.В C и некоторых похожих языках сравнение логических выражений на равенство
false
илиtrue
является опасной привычкой.В C любое скалярное выражение (числовое или указательное) может использоваться в логическом контексте, например, как условие
if
оператора. Правило C - это то, чтоif (cond)
эквивалентноif (cond != 0)
- т. Е. Ноль равен false, а любое ненулевое значение - true. Еслиcond
имеет тип указателя,0
обрабатывается как константа нулевого указателя;if (ptr)
значитif (ptr != NULL)
.Это значит, что
а также
не означает то же самое . Первое верно, если
cond
ненулевое; вторая верна, только если она равнаtrue
, что в C (если у вас есть#include <stdbool.h>
) просто1
.Например,
isdigit()
функция, объявленная в,<ctype.h>
возвращаетint
значение,0
если аргумент является цифрой, ненулевое, если это не так. Он может вернуться,42
чтобы указать, что условие истинно. Сравнение42 == true
не удастся.Бывает, что
0
это единственное значение, которое считается ложным, поэтому сравнение на равенствоfalse
будет работать;if (!cond)
иif (cond == false)
сделать то же самое. Но если вы собираетесь воспользоваться этим, вы должны помнить, что сравнивать сfalse
это нормально, а сравниватьtrue
- нет. Еще хуже то, что сравнениеtrue
будет работать большую часть времени (например, операторы равенства и реляционные операции всегда дают либо0
или1
). Это означает, что любые ошибки, которые вы вносите с помощью этого, все еще могут быть трудно отследить. (Не волнуйтесь, они появятся, как только вы представите код важному клиенту.)C ++ имеет немного другие правила; например, его
bool
тип немного более тесно интегрирован в язык иif (cond)
преобразуетсяcond
в типbool
. Но эффект (в основном) тот же.Некоторые другие языки имеют то, что можно назвать булевыми значениями с лучшим поведением, так что
cond == true
иcond == false
(или любой другой синтаксис) безопасен. Тем не менее, на каждом языке, который я видел, есть операторnot
или!
; это там, так что вы могли бы также использовать его. Использование,cond == false
а не!cond
илиnot cond
, на мой взгляд, не улучшает читаемость. (Это правда, что!
персонаж может быть трудно увидеть с первого взгляда; иногда я добавляю пробел после,!
чтобы избежать этого.)И часто вы можете избежать проблемы и улучшить ясность, слегка переставив код. Например, а не:
Вы могли бы написать:
Это не всегда лучше, но не мешает искать возможности там, где это есть.
Резюме: В C и C ++ сравнения на равенство
true
иfalse
опасны, слишком многословны и некачественны. Во многих других языках такие сравнения могут не быть опасными, но они все еще слишком многословны и некачественны.источник
== true
это небезопасно. Так лучше.(==True) . f
чтобы уточнить, что мы хотим-> Bool
создать экземпляр полиморфной функции returnf
. Это понятнееnot . not . f
и менее неловко, чем(f :: a -> Bool)
.pred(x)==pred(y)
функции, возвращающей boolpred
. Альтернатива, сpred(x)? pred(y) : !pred(y)
которой вы согласитесь, вряд ли приемлема.pred(x)
иpred(y)
используете одно и то же значение для обозначения истины, что является безопасным допущением в некоторых языках, но не в других. В C, например, вы можете написать!!pred(x) == !!pred(y)
.Эти два функционально идентичны, поэтому какой из них использовать - дело вкуса.
Основная причина, которую я использую,
== false
заключается в том, что я обнаружил, что!
это слишком легко упускать из виду при просмотре кода.Я был сильно укушен этим, и у меня появилась привычка ясно показывать это при проверке на ложность.
Если бы оператор был назван
not
как в Паскале, я не думаю, что это стало бы проблемой.источник
== false
вместо!
той же самой причины (чтобы выделить его). Однако не было никаких требований к использованию== true
, поэтому любое ненулевое значение по-прежнему работало как надо.!
, вероятно, является наиболее неприятной ошибкой такого рода, это должно привести к тому, что ИМО не будет создавать привычку писать,==false
а писать более качественные модульные тесты.Если для вас
condition == false
это действительно «намного более естественно на английском», то я должен предположить, что вы не являетесь носителем языка. В противном случае я не могу это объяснить, потому что никто не говорит так:Сравните это с
Тем не менее, я согласен с тем, что единственный тонкий
!
персонаж легко игнорируется в коде. По этой причине я предпочитаю ключевое слово,not
когда оно поддерживается языком. C ++, например , позволяет это, хотя многие программисты не знают об этом.Для языков, которые требуют
!
, я ставлю пробел между оператором и операндом. Это делает отрицание намного труднее пропустить:Обратите внимание, что каждый программист должен переводить это автоматически , не задумываясь, на «не состояние» в своей голове. Приобретение этого вида беглости в чтении идиом кода является одним из первых шагов в становлении хорошего программиста.
источник
Когда я вижу,
var == false
я всегда задаюсь вопросом,var
является ли это логическим или логическим типом с более чем двумя значениями (например, amaybe
и a,undefined
а такжеtrue
иfalse
или что-то вроде девяти значений IEEE 1164 ).источник
потому что иногда вы можете написать
boolean = false
(с очевидными ошибками) иfalse == boolean
не кажется естественным (независимо от того, насколько это хорошо для практики)источник
if( INVALID_HANDLE_VALUE == hFile )
избегать подобных вещей. Таким образом, если вы ошибетесь и используете один знак равенства вместо двух, вы получите ошибку компилятора. Очевидно, это работает только тогда, когда левое выражение является константой, но это спасло меня от головной боли, чем я могу сосчитать.hFile==INVALID_HANDLE_VALUE
письма.if (!boolean_variable)
переводится какif the condition is not true
.if (boolean == false)
переводится какif the condition not false is true
. Поскольку это обратная логика, ее сложнее понять.источник
isVisible
будет лучшим примером. Тогдаif (!isVisible)
будет означать, если не видно - что проще для понимания, тоif (isVisible==false)
есть обратная логика. Надеюсь, теперь стало понятнее. Или я неправильно понял ваш комментарий?Я полагаю, что в (гораздо) более старых компиляторах они будут разбиваться (boolean == false) на 2 назначения регистров и код сравнения на машинном языке. Первый пример будет разбит на одно присваивание и оператор NOT. С точки зрения производительности операция сравнения будет занимать несколько тактов в зависимости от размера сравниваемого регистра по сравнению с побитовым инвертированием (1 такт) и будет выполняться медленнее.
При этом, я считаю, что новые компиляторы покончат с этим, так что все должно быть в порядке.
источник
На работе я часто имею дело с логическими значениями, которые могут быть нулевыми, поэтому я буду часто кодировать этот случай как
потому что я лично чувствую, что симметрия облегчает чтение. Особенно, если есть и другие булевы тесты.
Мне действительно все равно, так или иначе.
источник
value == true
нет причин проверять, что это не NULL. Еслиvalue == null
оно никогда не должно запускать оператор if, то этогоif (value)
должно быть достаточно.if (value)
выдает исключение. Я был бы признателен, если бы люди, которые понизили голос, дали причину.value == true
будет достаточно.Когда вы тестируете истинное условие, имеет смысл выполнить это просто
if (condition)
, особенно когда вы применяете соглашение о присвоении имен логическим переменным, начинающимся с 'is':if (isOpen)
совершенно ясно и использование!= false
будет избыточным.Для C / C ++ / Java / и т. Д. программист, значение «!» оператор полностью ассимилирован до такой степени, что мы автоматически имеем «не» в наших умах, когда видим его. Так что иметь
if (!isOpen)
так же ясно, какif (_NOT_ isOpen)
для меня. Но вы недостаточно знакомы, в C / C ++ вы можете создать макрос с#define _NOT_ !
. Но поверьте мне, через несколько лет это совершенно не нужно.Кроме того, всегда предпочтительнее тестировать логические значения, не сравнивая их с литералами. Например, опасно проверять,
if (x == true)
потому что булево значение считается истинным, если оно не равно нулю, а литеральное истина имеет только одно конкретное значение, поэтому x может быть «истинным» (т. Е. Ненулевым), а сравнение все равно считается ложным (потому что оно содержит 2, и буквальное значение true, скажем, 1.) Конечно, это не относится к сравнению с false, но если вы не используете его при тестировании на true, зачем использовать его при тестировании на false?источник
Размер имеет значение ;)
В смешанных выражениях легче читать:
И особенно для ruby пример, где это большая разница:
ноль не ложь, но это также не правда.
источник
Основываясь на моем опыте и ответах на мой вопрос, с которыми вы связались.
Некоторые люди предпочитают использовать if (условие), потому что оно короче, чтобы написать. и для меня это действительно имеет смысл, например (! isValidated ()) я читаю это как не подтверждено. но для меня все это основано на личных предпочтениях, и это зависит от логической структуры метода isValidated (), если он возвращает либо true, либо false
источник
Если вы правильно назвали свою переменную, то
!boolean
это более естественно. Он читается какnot boolean
любой, кому достаточно программиста, чтобы читать код мысленно.источник
Для некоторых людей, чем скорее будет выражен смысл, тем лучше.
Для тех людей, у которых «if! ...» сравнивается быстрее с «if ...», тогда приходится читать все условия (которые на самом деле могут быть довольно длинными, например (thisThing = thatThing или что-то = другое) ИЛИ ( thinga = thingb и thinga = thingd) и т. д.), просто чтобы найти == false в конце.
Прочитав! (Я на самом деле предпочитаю «нет», когда язык это позволяет), сразу же появляется английское «не» для этого условия.
Эта проблема также заставляет задуматься об использовании
until
в языках, которые ее поддерживают, например, делать «обычные вещи» до тех пор, пока они не завершатся. Как говорят другие, целью является выражение на естественном языке. Мне нравится пример "солнце светит" выше.источник
Другая причина заключается в том, что если вы работаете в кодовой базе, которая использует несколько языков, если есть один идиоматический способ сделать что-то безопасное на всех языках, это хорошая идея сделать это везде так, чтобы у вас сформировалась хорошая привычка и с меньшей вероятностью споткнуться.
Я нигде не могу вспомнить, что
if (!variable)
(или эквиваленты, например, вif not variable
зависимости от вашего языка) небезопасны, в то время как, например,if self.is_ready() == False: ...
небезопасно в python, еслиself.is_ready()
возвращаетсяNone
, сейчас или в будущем, что было бы совершенно разумно для него сделать, чтобы указывают, что это не было готово, такNone
как столь же фальшиво какFalse
.источник