Если я использую'! IsGood' или 'IsGood == ложь'?

Лично, я предпочитаю форму, что Дядя Bob говорит о в Чистом Коде:

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

bool ShouldDoSomething()
{
    return IsGood;
}

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

Мы склонны делать следующее здесь:

if(IsGood)

или

if(IsGood == false)

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

if not IsNotGuam then

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

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

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

if (not foo ())
   bar ();

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

По некоторым причинам мне всегда нравилось

if (IsGood)

[больше чем 115]

if (!IsBad)

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

unless (IsBad)

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

raise InvalidColor unless AllowedColors.include?(color)

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

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

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

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

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

if (IsGood)
{
    DoSomething();
}

и

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

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

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

if (IsGood)
if (!IsGood)

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

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

• IsGood
• HasValue
• и т.д.

Метод тестирования конкретно против 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

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

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

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

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

• isalpha () == верный оценивает ко лжи??

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

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

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

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

if(IsGood) DoSomething();

или

if(IsBad == false) DoSomething();

вместо

if(!IsBad) DoSomething();

, Но снова, Это doen't имеют значение очень для меня, и я уверен, что это заканчивается как тот же IL.

Удобочитаемость только..

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

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

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

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

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

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

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

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

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

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

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

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

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

Обычно однако я согласился бы с Вами, что

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

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

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

Только хуже вещь

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

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

!IsGood шаблон легче найти, чем IsGood == false, когда уменьшено до регулярного выражения.

/\b!IsGood\b/

по сравнению с

/\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)

Я предпочел бы короче вариант. Но иногда == 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) { ... } не то же как [1 111]. Но этот не реалистичен;) перегрузка Оператора может вид справки здесь:) (и оператор, 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!");
                }
            }
        }
    }
}

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

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

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

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

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

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

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

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

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

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

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

if (Flag == true)

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

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

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

Если вы работаете с perl, у вас есть опция

unless($isGood)