Что мне следует использовать: `! IsGood` или` IsGood == false`?

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

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

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

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

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

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

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

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

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

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

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

Для реального сценария в проектах, использующих C # 2.0, я вижу только одну вескую причину для этого: bool? type. Три состояния 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!");
                }
            }
        }
    }
}

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

Согласно Code Complete, книга Джефф получил свое имя от и с большим уважением относится к следующему способу обращения с логическими значениями.

if (IsGood)
if (!IsGood)

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

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

• Хорошо
• HasValue
• и Т. Д.

Техника тестирования на истинность или ложь определенно является плохой практикой, если рассматриваемая переменная действительно предполагается использовать как логическое значение (даже если ее тип не является логическим) - особенно в 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

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

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

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

См. Этот вопрос SO, чтобы увидеть, где эта проблема на самом деле кого-то укусила ...

• isalpha () == true принимает значение false ??

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

Я часто вижу такие экземпляры SomeStringObject.ToString().

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

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

if(IsGood) DoSomething();

or

if(IsBad == false) DoSomething();

вместо

if(!IsBad) DoSomething();

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

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

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

Судя по полученным до сих пор ответам, это похоже на консенсус:

1. В большинстве случаев лучше всего подходит краткая форма. (IsGood и! IsGood)
2. Логические переменные следует записывать как положительные. (IsGood вместо IsBad)
3. Поскольку большинство компиляторов в любом случае выводят один и тот же код, разницы в производительности нет, за исключением интерпретируемых языков.
4. Этот вопрос без явного победителя, вероятно, можно рассматривать как битву в религиозной войне стиля кодирования.

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

if (IsGood)
{
    DoSomething();
}

и

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

поскольку я считаю это более читаемым - символ! его слишком легко пропустить (как при чтении, так и при наборе текста); также «if not IsGood, то ...» звучит не совсем правильно, когда я это слышу, в отличие от «if IsGood is false then ...», которое звучит лучше.

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

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

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

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

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

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

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

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

Однако в целом я согласен с вами, что

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

легче читать.

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

Единственное, что хуже

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

Никогда не понимал мысли, стоящей за этим методом.

Шаблон !IsGood легче найти, чем IsGood == false при преобразовании в регулярное выражение.

/\b!IsGood\b/

vs

/\bIsGood\s*==\s*false\b/
/\bIsGood\s*!=\s*true\b/
/\bIsGood\s*(?:==\s*false|!=\s*true)\b/

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

public bool IsBad => !IsGood;

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

if (IsBad)
{
    ...
}

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

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

if (something) ...

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

if (something == true) ...

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

Часто это не одно и то же.

Ты забыл:

если (IsGood == FileNotFound)

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

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

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

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

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

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

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

if (IsGood)

больше, чем

if (!IsBad)

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

unless (IsBad)

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

raise InvalidColor unless AllowedColors.include?(color)

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

if (not foo ())
   bar ();

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

Если вы действительно считаете, что вам нужно:

if (Flag == true)

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

if ((Flag == true) == true)

и так далее. Сколько еще гвоздей нужно этому гробу?

Если вы работаете с Perl, у вас есть возможность

unless($isGood)

Я не использую ==, но иногда использую !=, потому что это более ясно для меня. НО в моей работе мы не используем != или ==. Мы пытаемся получить имя, которое значимо с hasXYZ() или isABC().

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

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

bool ShouldDoSomething()
{
    return IsGood;
}

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

Здесь мы делаем следующее:

if(IsGood)

or

if(IsGood == false)

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

if not IsNotGuam then

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

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

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

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

if (!(IsGood ^ true))

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

true / 2

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

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

• истинный
• ложный
• null / undefined

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

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

OR

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
}

OR

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

Я думаю, это действительно зависит от языка.

Скажем, в PHP некоторые функции могут либо возвращать false, либо возвращать неотрицательные числа.

Тогда:

if(foo(bar)) { ... }

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

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

Один размер не подходит всем. Иногда более краткую форму можно сделать простой или идиоматической, например! (X% y), которая возвращает «Истина», если y является множителем x.

В других случаях более подробное сравнение было бы более полезным. [(x, y) для x в диапазоне (10) для y в диапазоне (10), если нет (x и y)] не так просто, как [(x, y) для x в диапазоне (10) для y в диапазоне (10) если (x == 0 или y == 0)]

Мне нравится использовать разные стили в зависимости от наименования переменных, например:

Переменные, названные с префиксом, например Is, Has и т. Д., С которыми, глядя на имя, очевидно, являются логическими, которые я использую:

if(IsSomething)

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

if(Something == true)

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

if(Something) and if(Something == true)

могут иметь очень разное значение на разных языках программирования.

Можно утверждать, что проверка типа if isValidDate == true может привести к чрезмерному вложению. Рассмотрим блок кода, который проверяет, что у нас есть действительные данные от пользователя, например:

if (isValidDate == true) {
    if (isValidQuantity == true) {
         if (isOtherThingValid == true) {
              bool result = doThing();
              if (result == true) {
                   thatWorked();
         } // long block of code that tries to compensate for OtherThing's invalidness
    } // obtuse function call to a third party library to send an email regarding the invalid quantity
} // is this the function close brace or the if...

Это сводит меня с ума, отчасти поэтому я выработал привычку делать все наоборот:

if (isValidDate == false) {
    logThisProblem("Invalid date provided.");
    return somethingUseful;
}

if (isValidQuantity == false) {
    logThisProblem("Invalid quantity provided.");
    return somethingUseful;
}

if (isOtherThingValid == false) {
    logThisProble("Other thing not valid.");
    return somethingUseful;
}

// OK ... we've made it this far...
bool result = doThing(date, quantity, otherThing);

На таком языке, как C, где нет "логического" типа, я рекомендую более длинный путь, т.е.

if (is_good == True)
{
}

Причина в том, что is_good не только _2 _ / _ 3_ (скорее всего, реализовано как char) и, следовательно, может быть повреждено другими значениями или неправильно установлено.

Так что в этом хорошего? Ваш код сможет выявить любые проблемы, связанные с неправильной установкой is_good, потому что без проверки == True или == False все пойдет на истину;) И если вы действительно имеете в виду логическое значение, то это плохо.

Пока у нас есть if (isGood) или if (!isGood), все в порядке.

Иногда мне попадается такой код ...

if (!getGreatGrandFateher.getGrandFather().getFather().getFirstChild().isMale())
{
   doSomething();
}

На первый взгляд это вводит в заблуждение, что doSomething вызывается, если это Male. Маленький '!' после "if" теряется в большой конструкции кода, подобной приведенной выше.

Явная проверка, как показано ниже, обеспечивает лучшую читаемость

if(getGreatGrandFateher.getGrandFather().getFather().getFirstChild().isMale() == false)
{
   doSomething();
}

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

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

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

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

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

над

if (something)
if (!something)

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

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

if something:
if not something:

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

я буду

if (isGood) {
  doSomething();
}

и

if (isNotGood) {
    doSomethngElse();
}

Читает лучше.