Должен ли я использовать `! IsGood` или` IsGood == false`?

Я продолжаю видеть код, который делает проверки, как это

if (IsGood == false)
{
   DoSomething();
}

или это

if (IsGood == true)
{
   DoSomething();
}

Я ненавижу этот синтаксис и всегда использую следующий синтаксис.

if (IsGood)
{
   DoSomething();
}

или

if (!IsGood)
{
   DoSomething();
}

Есть ли причина использовать == true«или == false»?

Это удобочитаемость? Люди просто не понимают булевых переменных?

Кроме того, есть ли разница в производительности между этими двумя?

10.12.2008 14:23:51
Если это действительно беспокоит вас, это будет долгая и тяжелая жизнь для вас.
GEOCHET 10.12.2008 14:26:27
Это справедливый вопрос, который кажется мне не слишком раздражающим.
annakata 10.12.2008 14:29:04
Да, это действительно. Время от времени я сомневаюсь в простых вещах и время от времени нахожу веские причины изменить свои пути ...
Michael Haren 10.12.2008 14:31:15
Крис, это не вопрос разветвленной структуры. C напечатан, но не имеет логического типа. «if (good)» отличается от «if (good == TRUE)». Первое означает, что хорошо это не ноль. Второе означает, что good в точности равно TRUE, что является конкретным целочисленным значением. Смотрите MikeB ответ для более.
Jim Nelson 12.12.2008 20:50:32
На мой взгляд, главная проблема в том, что разработчик выглядит так, будто он не понимает логические значения
JoelFan 13.05.2010 15:51:56
30 ОТВЕТОВ
РЕШЕНИЕ

Я придерживаюсь того же синтаксиса, что и вы, он менее многословен.

Люди (более начинающие) предпочитают использовать == trueтолько для того, чтобы быть уверенными, что это то, что они хотят. Они привыкли использовать оператор в своих условных выражениях ... они нашли его более читабельным. Но как только вы стали более продвинутым, вы почувствовали раздражение, потому что это слишком многословно.

104
5.06.2018 02:33:01
Это не просто новички, которые предпочитают это; тот, кто заинтересован в максимизации читабельности кода, предпочитает его. Какая стоимость?
Chris 10.12.2008 16:34:30
Я нашел это более читабельным в более коротком виде ... какова цель направо == верно, когда левая сторона уже верна / ложна ... Не говори "никому" ... Я согласен с Даоком, я делал это несколько месяцев назад, чем осознать мою ошибку
Pokus 10.12.2008 16:41:24
Если вы правильно называете свои переменные, то добавление оператора фактически снижает читабельность. Т.е. когда вы читаете это, «если это хорошо» более читабельно, чем «если это хорошо, это правда». Я говорю «if (isGood)» так ясно, как только может быть.
Marko Dumic 10.12.2008 16:44:56
56 голосов за почти тривиальное мнение? Ха, этот сайт вышел из-под контроля.
JC. 10.12.2008 18:20:48
Когда я вижу == для логических типов, я думаю, что это показатель того, что человек, который использует ==, полностью понимает логическую логику и что это значит.
Lara Dougan 16.12.2008 18:05:27

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

3
5.06.2018 02:47:12
Я думаю, что вы имеете в виду «семантически». Строго говоря, между ними есть разница, потому что используемые операторы (включая false) могут быть переопределены. Кроме того (в зависимости от вашего уровня семантики), оба описывают различные оценки (хотя компилятор, скорее всего, использует то же самое для обоих).
mweerden 10.12.2008 15:05:11

Я согласен с вами (и меня это тоже раздражает). Я думаю, что это всего лишь небольшое недоразумение, IsGood == trueс boolкоторого IsGoodнужно начинать.

Я часто вижу эти близкие случаи SomeStringObject.ToString().

Тем не менее, в языках, которые играют слабее с типами, это может быть оправдано. Но не в C #.

13
5.06.2018 02:49:13
Хорошая точка зрения на это, что она появляется рядом с String.ToString (), но мне было бы любопытно узнать, может ли это быть привычкой для некоторых разработчиков, которые привыкли к языкам, которые более свободны в своих типах данных.
rjzii 10.12.2008 15:53:09
Верно об этом, оценивая как bool, с чего вы начали. Где вы остановитесь тогда? ((isGood == false) == true)? Нет, это тоже bool, (((isGood == false) == true) == true) и так далее ... Сравнение bools с bools просто означает, что вы делаете это неправильно ...: p
jalf 10.12.2008 16:37:44

Только читабельность ..

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

7
10.12.2008 14:27:33

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

Хорошим примером этого может быть strcmp () C / C ++, который возвращает 0, если строки равны, иначе <или> 0, в зависимости от того, где находится различие. Так что вы часто будете видеть:

if(strcmp(string1, string2)==0) { /*do something*/ }

Как правило, однако я согласен с вами, что

if(!isCached)
{
    Cache(thing);
}

понятнее читать.

4
10.12.2008 14:28:58
Как только вы понимаете strcmp, это будет лучше, если (! Strcmp (string1, string2)) {/ * сделать что-то * /}
David Allan Finch 10.12.2008 15:00:59
Выполнение! Strcmp хуже, потому что вы смешиваете логические операторы с нелогическими значениями. strcmp == 0 /! = 0 - более правильный и понятный метод.
Torlack 10.12.2008 15:24:04
В прошлом у меня возникали проблемы с strcmp, когда я не полностью осознавал, что он возвращает, в основном из-за того, что он использовался как! Strcmp () в большинстве мест. В целом, я обнаружил, что писать == 0 не так уж и многословно, и это делает абсолютно ясным, что вы ожидаете от него.
xan 11.12.2008 12:48:40
Обычно я использую встроенную функцию или макрос isEqual, который вызывает! Strcmp. Фактически, в моем коде на C ++ я теперь использую класс-оболочку char * с именем cStrBuff, который имеет служебные функции и операторы.
David Allan Finch 11.12.2008 14:19:39
Аналогично strcmp, если не булева переменная тестируется булевым способом, как здесь: if (count) {count--;} мне всегда требуется дополнительное время, чтобы понять, что count не является логическим значением, и мы тестируем что-то еще здесь ,
Purple Tentacle 9.11.2010 20:04:50

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

if(IsGood) DoSomething();

или

if(IsBad == false) DoSomething();

вместо

if(!IsBad) DoSomething();

Но опять же, это не имеет большого значения для меня, и я уверен, что это в конечном итоге, как тот же IL.

9
10.12.2008 14:29:21
Это то, что я делаю. Если я ищу ложное, я делаю == ложное, но я стараюсь этого не делать. Я бы предпочел вообще не инвертировать условное. Обычно имеет смысл рефакторировать isBad на isGood или поменять ваши блоки if / else, чтобы придать им больше смысла, или что-то еще.
Adam Jaskiewicz 10.12.2008 15:20:10
Если вы видите, если (IsGood) вы также можете сделать вывод, что это логическое значение, в противном случае он не будет компилироваться! ;) В любом случае, вы правы, начинающие, как правило, видят в этом ясность.
rgargente 10.12.2008 16:39:41

Лично я предпочитаю форму, о которой говорит дядя Боб в Чистом коде:

(...)
    if (ShouldDoSomething())
    {
        DoSomething();
    }
(...)

bool ShouldDoSomething()
{
    return IsGood;
}

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

1
5.06.2018 02:45:16
Я не хочу идти куда-то еще, чтобы понять, что означает «следует делать».
Randy Stegbauer 10.12.2008 19:32:21
Я не согласен с комментарием выше. Обычно думают с точки зрения рабочего процесса, который во многих случаях важнее самой реализации условия.
Mauli 11.12.2008 08:58:45
Моя точка зрения точно. Если вы учитываете объем мозговых затрат, затрачиваемых на просмотр кода, вы экономите часть, когда вас не беспокоит слишком много деталей.
mookid8000 11.12.2008 19:08:40
Если тело утверждения просто «сделать что-то», зачем вам нужно условие «если что-то делать» ... это очевидно. Если такое же условие не используется в другом месте, я думаю, что это не нужно.
Connell 16.07.2012 15:01:30
Это глупо. Зачем бросать в стек другую функцию просто для того, чтобы вернуть одну переменную, которую легко можно было бы использовать напрямую? Это простой метод, вы также можете сделать его getединственным свойством, но оно просто вернется, IsGoodпоэтому вы можете просто использовать его напрямую и не заставлять читателя беспокоиться, если ShouldDoSomethingэто какой-то дорогой метод
AustinWBryan 5.06.2018 02:45:10

Я бы предпочел более короткий вариант. Но иногда == falseпомогает сделать ваш код еще короче:

Для реальных сценариев в проектах, использующих C # 2.0, я вижу только одну вескую причину сделать это: bool?тип. Три состояния bool?полезны, и таким образом легко проверить одно из возможных значений.

На самом деле вы не можете использовать, (!IsGood)если IsGoodесть bool?. Но написание (IsGood.HasValue && IsGood.Value)хуже чем (IsGood == true).

Поиграйте с этим примером, чтобы получить представление:

bool? value = true; // try false and null too

if (value == true)
{
    Console.WriteLine("value is true");
}
else if (value == false)
{
    Console.WriteLine("value is false");
}
else
{
    Console.WriteLine("value is null");
}

Есть еще один случай, который я только что обнаружил, где if (!IsGood) { ... }он не такой, как if (IsGood == false) { ... }. Но этот нереалистичен;) Перегрузка операторов может здесь помочь :) (и оператор true / false, что AFAIK не рекомендуется в C # 2.0, потому что это предназначено для обеспечения bool? -Подобного поведения для определяемого пользователем типа и теперь Вы можете получить это со стандартным типом!)

using System;

namespace BoolHack
{
    class Program
    {
        public struct CrazyBool
        {
            private readonly bool value;

            public CrazyBool(bool value)
            {
                this.value = value;
            }

            // Just to make nice init possible ;)
            public static implicit operator CrazyBool(bool value)
            {
                return new CrazyBool(value);
            }

            public static bool operator==(CrazyBool crazyBool, bool value)
            {
                return crazyBool.value == value;
            }

            public static bool operator!=(CrazyBool crazyBool, bool value)
            {
                return crazyBool.value != value;
            }

            #region Twisted logic!

            public static bool operator true(CrazyBool crazyBool)
            {
                return !crazyBool.value;
            }

            public static bool operator false(CrazyBool crazyBool)
            {
                return crazyBool.value;
            }

            #endregion Twisted logic!
        }

        static void Main()
        {
            CrazyBool IsGood = false;

            if (IsGood)
            {
                if (IsGood == false)
                {
                    Console.WriteLine("Now you should understand why those type is called CrazyBool!");
                }
            }
        }
    }
}

Так что ... пожалуйста, используйте перегрузку оператора с осторожностью :(

32
5.06.2018 02:37:53
(IsGood == true) также не сработает, если IsGood является недействительным булом. Вам нужно написать (IsGood.HasValue && IsGood.Value == true), который все еще более многословен и, возможно, менее ясен, чем (IsGood.HasValue && IsGood.Value)
Charles Bretana 10.12.2008 15:18:38
Чарльз, я думаю, ты не прав. Для Nullable <T> вы получите T как тип свойства Value (в нашем случае bool, поэтому (... && IsGood.Value) должно работать). Также вы можете использовать самую короткую форму тоже. Попробуйте поиграть с образцом, который я только что добавил, чтобы ответить.
IgorK 10.12.2008 15:26:01
IgorK, я согласен, [IsGood.Value] будет работать, (если IsGood имеет значение ...) Я говорил, что просто написать IsGood == true не будет работать, если IsGood Nullable <bool> В этом случае IsGood НЕ является bool, это Nullable <bool>, так что вы не можете сравнить его с «true», что привело бы к несоответствию типов
Charles Bretana 10.12.2008 15:51:04
Чарльз, первый пример работает для всех трех случаев (когда IsGood набрал bool? Инициализируется с true, false или null). Я проверил это еще раз. Вы говорите, что первый пример не будет компилироваться с использованием компилятора C # 2.0? Это действительно ... Нет исключений в нулевом случае тоже :)
IgorK 10.12.2008 15:56:06
Я бы предпочел, чтобы (IsGood.GetValueOrDefault ()), которые имели тот же эффект и были быстрее (время выполнения), чем если (IsGood.HasValue && IsGood.Value). Обратите внимание, что if (! IsGood.GetValueOrDefault ()) НЕ совпадает с if (IsGood.HasValue &&! IsGood.Value).
P Daddy 10.12.2008 21:51:24

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

if (IsGood)
if (!IsGood)

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

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

  • Хороший
  • HasValue
  • и т.п.
18
10.12.2008 14:35:27

Я предпочитаю подход ! IsGood , и я думаю, что большинство людей с языком в стиле c также предпочтут его. Я только догадываюсь здесь, но я думаю, что большинство людей, которые пишут IsGood == False, происходят из более многословного языка, такого как Visual Basic.

3
10.12.2008 14:37:22
тем более, что в Visual Basic «Not IsGood» более читабелен, чем «IsGood = False»
Jimmy 10.12.2008 16:36:04

Мне кажется (хотя у меня нет доказательств, подтверждающих это), что люди, начинающие на языках типов C # / java, предпочитают метод "if (CheckSomething ())", тогда как люди, начинающие на других языках (C ++: в частности, Win32) C ++) склонны использовать другой метод по привычке: в Win32 «if (CheckSomething ())» не будет работать, если CheckSomething возвращает BOOL (вместо bool); и во многих случаях функции API явно возвращают 0/1 int / INT, а не значение true / false (то есть, что такое BOOL).

Я всегда использовал более многословный метод, опять же, по привычке. Они синтаксически одинаковы; Я не покупаю ерунду "многословие раздражает меня", потому что программист - это не тот, кого должен впечатлять код (это делает компьютер). И в реальном мире уровень квалификации любого конкретного человека, смотрящего на написанный мною код, будет варьироваться, и у меня нет времени или желания объяснять особенности оценки высказываний тому, кто может не понимать незначительное незначительное. такие биты

1
10.12.2008 14:42:16
Компилятор не дает облизать код. Программист (и, что более важно, более поздние программисты) должен быть впечатлен. Вы можете выбросить все правила форматирования и стиля, и компилятор не будет обеспокоен, но ментальные потери для любого, кто читает код, будут огромными
Diastrophism 10.12.2008 22:51:17

Здесь мы склонны делать следующее:

if(IsGood)

или

if(IsGood == false)

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

if not IsNotGuam then

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

0
10.12.2008 14:43:55

Для удобства чтения вы можете рассмотреть свойство, которое зависит от другого свойства:

public bool IsBad => !IsGood;

Тогда вы действительно сможете понять значение:

if (IsBad)
{
    ...
}
3
5.06.2018 02:45:39
Это на самом деле одна из моих любимых мозолей. Где-то вдоль линии меня учили, что логические выражения должны представлять собой положительные условия. Использование отрицательных условий неизбежно приводит к странным двойным отрицательным тестам, таким как «if (! IsBad ||! Uninitialized)», помещающим мозг разработчика в мягкий крендель с солью.
benjismith 10.12.2008 15:24:15
Но, если у вас есть следствие IsGood и IsBad, вам никогда не нужно делать что-то вроде! IsBad
Brian Genisio 10.12.2008 15:29:05
Если вам нравятся исключения переполнения стека ... public bool IsBad {get {return! IsGood; }} public bool IsGood {get {return! IsBad; }}
GalacticCowboy 10.12.2008 17:06:36
Что делать, если вы забыли, что IsBadэто свойство или что-то? !IsGoodследует читать Is not Goodтак, как он встроен
AustinWBryan 5.06.2018 02:46:47

Единственный раз, когда я могу подумать, где более подробный код имеет смысл, был до .NET Visual Basic, где true и false были фактически целыми числами (true = -1, false = 0), а логические выражения считались ложными, если они оценивались в ноль и истина для любых других ненулевых значений. Таким образом, в случае старого VB два перечисленных метода на самом деле не были эквивалентны, и если вы только хотели, чтобы что-то было истинным, если оно оценивается как -1, вы должны явно сравнить с «истиной». Таким образом, выражение, которое оценивается как «+1», будет истинным, если будет оценено как целое число (потому что оно не равно нулю), но оно не будет эквивалентно «истинному». Я не знаю, почему VB был разработан таким образом, но я вижу много логических выражений, сравнивающих переменные с истиной и ложью в старом коде VB.

0
10.12.2008 15:12:40

Хотя это не практическая разница, я всегда рассматриваю == как числовой оператор, и как таковой он не применим к логическим типам. Ближайший логический оператор - это «эквивалентность» (не исключающий или), у которого нет оператора в стиле C.

Таким образом, строго логический тест становится

if (!(IsGood ^ true))

В качестве иллюстрации проблем с числовыми операторами на логических значениях, какова логическая оценка

true / 2
0
10.12.2008 15:47:24
Насколько я знаю, C-стиль '^' обычно представляет собой числовой оператор (т.е. побитовый xor). На самом деле C-подобные языки часто не имеют логических значений. Обратите внимание, что! B в этих языках эквивалентно b == 0. (Кроме того, алгебраически это вообще не проблема.)
mweerden 10.12.2008 17:07:45
Если вы используете Python 3.0, True / 2 оценивается как True. Если Python 2.X, True / 2 оценивается как False. То, что имеет значение, остается в качестве упражнения для читателя. :)
J.T. Hurley 11.12.2008 08:47:37
== не является числовым оператором. Вы также можете использовать его с логическими типами, по крайней мере, в C ++. Таким образом, вы можете написать if (oneBool == anotherBool) ...
Daniel Daranas 18.05.2009 12:13:15

Я всегда смеюсь (или бросаю что-то в кого-то, в зависимости от моего настроения), когда сталкиваюсь

if (someBoolean == true) { /* ... */ }

потому что, конечно, если вы не можете полагаться на тот факт, что ваше сравнение возвращает логическое значение, то вы также не можете полагаться на сравнение результата с истинным, поэтому код должен стать

if ((someBoolean == true) == true) { /* ... */ }

но, конечно, это действительно должно быть

if (((someBoolean == true) == true) == true) { /* ... */ }

но конечно ...

(Ах, сборка не удалась. Вернуться к работе.)

38
10.12.2008 15:55:45
Shades of Monty Python и набросок спама ... Мне нужен тест If со спамом, спамом, спамом, правдой и спамом .....
Ken Ray 10.12.2008 19:19:31

Возможно (хотя и маловероятно, по крайней мере, я надеюсь), что в коде C TRUE и FALSE # определены для вещей, отличных от 1 и 0. Например, программист, возможно, решил использовать 0 как "true" и -1 как "false «в конкретном API. То же самое относится и к унаследованному коду C ++, поскольку «true» и «false» не всегда были ключевыми словами C ++, особенно в тот день, когда существовал стандарт ANSI.

Стоит также отметить, что некоторые языки, особенно такие как script-y, как Perl, JavaScript и PHP, могут смешно интерпретировать, какие значения считаются истинными, а какие - ложными. Возможно (хотя, опять-таки, вряд ли на надежде), что "foo == false" означает что-то немного отличное от "! Foo". Этот вопрос помечен как «независимый от языка», и язык может определить оператор ==, чтобы он не работал способами, совместимыми с! оператор.

5
10.12.2008 16:01:08
Есть также тонкое поведение в C / C ++, где все, что не равно нулю, «истинно», но не обязательно == TRUE.
GalacticCowboy 10.12.2008 17:01:53

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

if (IsGood == false)лучше чем if(!IsGood).

При сканировании кода легко ошибиться "!" предшествующая переменная bool для символа в переменной bool.

0
5.06.2018 02:54:44

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

Вот пример. В ActionScript 2 логические значения имеют 3 возможных значения:

  • правда
  • ложный
  • нуль / не определено

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

function myFunc(b:Boolean):Void {
  if(b == true) {
    // causes b to default to false, as null/undefined != true
  }
}

ИЛИ

function myFunc(b:Boolean):Void {
  if(b != false) {
    // causes b to default to true, as null/undefined != false
  }
}

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

function myFunc(b:Boolean):Void {
  b = (b == true); // default to false
}

ИЛИ

function myFunc(b:Boolean):Void {
  b = (b != false); // default to true
}
0
10.12.2008 16:10:04

Ах, у меня есть кое-что в пользу более длинной формы, утверждая, что она более читаема, чем крошечная!

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

Если вы правильно пишете имя вашей логической переменной, оно должно выглядеть естественно:
if (isSuccessful)vs.if (returnCode)

В некоторых случаях я мог бы заниматься булевым сравнением, например:
if (PropertyProvider.getBooleanProperty(SOME_SETTING, true) == true)потому что оно читается менее «естественно».

1
10.12.2008 16:30:18

Техника тестирования специально против true или false определенно является плохой практикой, если рассматриваемая переменная действительно должна использоваться в качестве логического значения (даже если ее тип не является логическим), особенно в C / C ++. Тестирование trueможет (и, вероятно, приведет) к незначительным ошибкам:

Эти явно похожие тесты дают противоположные результаты:

// needs C++ to get true/false keywords
// or needs macros (or something) defining true/false appropriately
int main( int argc, char* argv[])
{
    int isGood = -1;

    if (isGood == true) {
        printf( "isGood == true\n");
    }
    else {
        printf( "isGood != true\n");
    }

    if (isGood) {
        printf( "isGood is true\n");
    }
    else {
        printf( "isGood is not true\n");
    }

    return 0;
}

Это отображает следующий результат:

isGood != true
isGood is true

Если вы чувствуете необходимость проверить переменную, которая используется в качестве логического флага, против true / false (что, по моему мнению, не следует делать), вы должны использовать идиому всегда проверять против false, потому что false может иметь только одно значение ( 0) в то время как true может иметь несколько возможных значений (что угодно, кроме 0):

if (isGood != false) ...  // instead of using if (isGood == true)

У некоторых людей будет мнение, что это недостаток C / C ++, и это может быть правдой. Но это факт жизни в этих языках (и, возможно, во многих других), поэтому я бы придерживался краткой идиомы, даже в таких языках, как C #, которые не позволяют использовать интегральное значение в качестве логического значения.

Посмотрите этот ТАК вопрос для примера, где эта проблема на самом деле укусила кого-то ...

15
23.05.2017 12:17:20

Мне почему-то всегда нравилось

if (IsGood)

больше, чем

if (!IsBad)

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

unless (IsBad)

и даже больше, если используется так:

raise InvalidColor unless AllowedColors.include?(color)
1
10.12.2008 16:53:46

Из ответов до сих пор, это, кажется, консенсус:

  1. Краткая форма лучше всего подходит в большинстве случаев. (IsGood и! IsGood)
  2. Булевы переменные должны быть записаны как положительные. (IsGood вместо IsBad)
  3. Поскольку большинство компиляторов будут выводить один и тот же код в любом случае, разницы в производительности нет, за исключением случаев интерпретируемых языков.
  4. Эта проблема не имеет явного победителя, вероятно, можно рассматривать как битву в религиозной войне в стиле кодирования.
7
10.12.2008 17:19:52
Я не согласен с тем, что нет явного победителя - особенно в C / C ++. Это не просто вопрос стиля, могут быть семантические различия. Использование более длинной формы может вызвать незначительные ошибки.
Michael Burr 10.12.2008 17:27:55
Но использование более длинной формы может вызвать незначительные ошибки. if (isGood = false)можно было бы избежать, просто используя!
AustinWBryan 5.06.2018 02:48:43

Я предпочитаю использовать:

if (IsGood)
{
    DoSomething();
}

а также

if (IsGood == false)
{
    DoSomething();
}

как я нахожу это более читабельным! слишком легко пропустить (как при чтении, так и при наборе текста); также "если не IsGood тогда ..." просто не звучит правильно, когда я слышу это, в отличие от "если IsGood ложно тогда ...", что звучит лучше.

6
10.12.2008 17:20:25

Во многих языках разница в том, что в одном случае компилятор / интерпретатор диктует значение true или false, а в другом случае это определяется кодом. C является хорошим примером этого.

if (something) ...

В приведенном выше примере «что-то» сравнивается с определением компилятора «true». Обычно это означает «не ноль».

if (something == true) ...

В приведенном выше примере «что-то» сравнивается с «истиной». Тип «истина» (и, следовательно, сопоставимость) и значение «истина» могут определяться или не определяться языком и / или компилятором / интерпретатором.

Часто эти два понятия не совпадают.

2
10.12.2008 17:41:25

Только хуже

if (true == IsGood) {....

Никогда не понимал, что стоит за этим методом.

3
10.12.2008 18:21:47
Я думаю, что это происходит из C ++. Если вы допустите ошибку и напишите «if (x = 6)», найти эту ошибку будет очень сложно, тогда как «if (6 = x)» приведет к ошибке компиляции.
gius 10.12.2008 19:28:57
Как только вы привыкнете смотреть на это, нет проблем с чтением. Вроде как привыкнуть читать по-английски?
Diastrophism 10.12.2008 22:49:29
Я ненавижу видеть это. Вы не скажете: «Красный был цветом машины», если вы не звучите глубоко или не любите. Вы бы просто сказали: «Цвет машины был красным».
AustinWBryan 5.06.2018 02:42:20

Я видел следующее как требование стиля C / C ++.

if ( true == FunctionCall()) {
  // stuff
}

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

5
10.12.2008 18:51:43
Я не слежу за этим. Если вам не требуется '==', вы случайно не набираете '='
Jimmy 12.12.2008 22:23:57
Это на самом деле помогает удобочитаемости (после привыкания (не займет много времени)). Положив короткий элемент в начале всегда рекомендуется ( SomLongFunctionCall(*pointer[3], file == NOFILE, GetMyHeap(1, ALWAYS)) == E_NOERRэто гораздо проще на глаз наоборот: E_NOERR == SomLongFunctionCall(*pointer[3], NOFILE == file, GetMyHeap(1, ALWAYS))YMMV как обычно..
bobbogo 9.03.2011 18:50:25

Кодирование на C # / C ++ / Java / etc ... Я всегда предпочитаю

if (something == true)
if (something == false)

над

if (something)
if (!something)

потому что восклицательный знак сложно увидеть с первого взгляда, если бы я не использовал большой шрифт (но тогда я бы увидел меньше кода на странице - не все из нас могут позволить себе мониторы с диагональю 24 дюйма +). Мне особенно не нравится быть несовместимы и используют if (something)иif (something == false)

Когда я пишу код на Python, я почти всегда предпочитаю

if something:
if not something:

потому что «не» ясно видно.

-1
5.06.2018 02:50:56
В python слова «если что-то:» и «если что-то == правда» означают разные вещи. В C ++ true может неявно преобразовывать в 1, поэтому если «что-то» будет целым числом, содержащим значение 2, тогда «что-то == true» будет ложным, но «(! Что-то) == true» также будет ложным!
Aaron 11.12.2008 01:57:43
Я знаю, что это технически отличается, но я имею в виду логические переменные. «if isGood:» или «если не isGood:». Но вы правы, эта идиома не будет работать, если мне нужно будет отличить None от, например, пустого списка. Я стараюсь избегать этого, хотя.
Cybis 11.12.2008 02:28:25

!IsGoodКартина eaiser найти , чем IsGood == falseкогда сводится к регулярному выражению.

/\b!IsGood\b/

против

/\bIsGood\s*==\s*false\b/
/\bIsGood\s*!=\s*true\b/
/\bIsGood\s*(?:==\s*false|!=\s*true)\b/
3
10.12.2008 19:18:37

Cybis, при кодировании на C ++ вы также можете использовать ключевое слово not . Это часть стандарта с давних времен, так что этот код совершенно действителен:

if (not foo ())
   bar ();

Изменить: Кстати, я забыл упомянуть, что стандарт также определяет другие логические ключевые слова, такие как и (&&), bitand (&) или (||), bitor (|), xor (^) ... Они называются оператором синонимы.

1
10.12.2008 21:49:18
Ты узнаешь что-то новое каждый день. Я читал МНОЖЕСТВО статей, учебников, книг по С ++, посещал ориентированные на С ++ занятия в университете, но никогда раньше не видел этот синтаксис. Спасибо.
Cybis 10.12.2008 21:35:32
Это должно было произойти, когда этот парень из VB присоединился к комитету по стандартам C ++!
P Daddy 10.12.2008 22:15:49
@P Daddy: да, еще в 1980-х годах, когда Бьярн Страуструп разрабатывал C ++, он позаимствовал машину времени Кнута, чтобы перейти к 90-м годам, когда люди ломают голову над программистами на VB. Или, может быть, вы никогда не слышали об Алголе .
Aaron 11.12.2008 02:14:19