Плохо ли это явно сравнивать с булевыми константами, например. if (b == false) в Java?

Ответ 1

Это не обязательно плохо, это просто лишнее. Кроме того, фактическое имя переменной сильно различается. Я бы предпочел, например, if (userIsAllowedToLogin) выше if (b) или даже хуже if (flag).

Что касается производительности, то компилятор каким-либо образом оптимизирует ее.

Обновить: что касается авторитетных источников, я не могу найти что-то явно в Sun Coding Conventions, но по крайней мере Checkstyle имеет SimplifyBooleanExpression модуль который предупредил бы об этом.

Ответ 2

Нельзя использовать первый стиль. Я видел, как люди использовали:

• if ( b == true )
• if ( b == false )

Мне лично трудно читать, но это сносно. Однако большая проблема, с которой я сталкиваюсь в этом стиле, заключается в том, что это приводит к невероятно противоречивым примерам, которые вы показали:

• if ( b != true )
• if ( b != false )

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

Ответ 3

Это сильно зависит от вкуса.

Лично я обнаружил, что if (!a) { намного менее читаемый (EDIT: для меня), чем if (a == false) { и, следовательно, больше подвержен ошибкам при сохранении кода позже, и я преобразовал его в последнюю форму.

В основном мне не нравится выбор символов для логических операций вместо слов (C по сравнению с Pascal), потому что для меня a = 10 and not b = 20 читается легче, чем a == 10 && !(b==20), но так оно и есть в Java.

Любой, кто ставит "== ложный" подход в сторону "!" явно никогда не уставился на код слишком долго и пропустил этот восклицательный знак. Да, вы можете получить код-слепой.

Ответ 4

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

if (b = false) //...

while (b = true) //...

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

Ответ 5

Я никогда не видел первого, кроме кода, написанного новичками; это всегда последнее, и я не думаю, что кто-то действительно смущен этим. С другой стороны, я думаю,

int x;
...
if(x) //...

против

if(x != 0) //...

гораздо более спорно, и в этом случае я предпочитаю второй

Ответ 6

IMHO, я думаю, если вы просто сделаете имена переменных bool, добавленные с помощью "Is", это будет самоочевидным и более значимым, а затем вы можете удалить явное сравнение с true или false

Пример:

isEdited  // use IsEdited in case of property names
isAuthorized // use IsAuthorized in case of property names

и т.д.

Ответ 7

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

Ответ 8

Я предпочитаю длинный подход, но я сравниваю использование == вместо != 99% времени.

Я знаю, что этот вопрос касается Java, но я часто переключаюсь между языками, а в C#, например, сравнение с (для isntance) == false может помочь при работе с обнуленными типами bool. Поэтому я получил эту привычку сравнивать с true или false, но с помощью оператора ==.

Я делаю это:

if(isSomething == false) или if(isSomething == true)

но я их ненавижу:

if(isSomething != false) или if(isSomething != true)

по очевидным причинам удобочитаемости!

Пока вы сохраняете свой код читаемым, это не имеет значения.

Ответ 9

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

if (b == false) {
   // false
} else {
   // true
}

или

boolean b = false;
while(b == false) {
  if (condition)
      b = true;
}

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

Ответ 10

По-моему, это просто раздражает. Не то, что я мог бы вызвать шум, хотя.

Ответ 11

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

Сегодня утром я потерял полчаса, чтобы найти ошибку. Код был

    if ( !strcmp(runway_in_use,"CLOSED") == IPAS_FALSE)
      printf(" ACTIVE    FALSE \n");   else
      printf(" ACTIVE    TRUE \n");

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

    if (strcmp(runway_in_use, "CLOSED"))
      printf(" ACTIVE    FALSE \n");   else
      printf(" ACTIVE    TRUE \n");

Ответ 12

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

for (Alert alert : alerts) {
    Long currentId = alert.getUserId();

    if (vipList.contains(currentId)) {
        customersToNotify.add(alert);

        if (customersToNotify.size() == maxAlerts) {
            break;
        }
    }
}

а другой

for (Alert alert : alerts) {
    Long currentId = alert.getUserId();

    if (!vipList.contains(currentId)) {
        customersToNotify.add(alert);

        if (customersToNotify.size() == maxAlerts) {
            break;
        }
    }
}

поэтому в этом случае имеет смысл создать метод, который работал для обоих условий, подобных этому, используя boolean == condition чтобы перевернуть значение

private void appendCustomersToNotify(List<Alert> alerts
        List<Alert> customersToNotify, List<Long> vipList, boolean vip){

    for (Alert alert : alerts) {
        Long currentId = alertItem.getUserId();

        if (vip == vipList.contains(currentId)) {
            customersToNotify.add(alertItem);

            if (customersToNotify.size() == maxAlerts) {
                break;
            }
        }
    }
}

Ответ 13

Я бы сказал, что это плохо.

while (!b) {
    // do something 
}

читается намного лучше, чем

while (b != true) {
    // do something 
}

Ответ 14

Одна из причин, по которой первый (b == false) недооценивается, заключается в том, что новички часто не понимают, что вторая альтернатива (! b) возможна вообще. Поэтому использование первой формы может указывать на неправильное представление с булевыми выражениями и логическими переменными. Таким образом, использование второй формы стало своего рода sjiboleth: когда кто-то пишет это, он, вероятно, понимает, что происходит.

Я считаю, что это заставило разницу считать более важной, чем она есть на самом деле.