Плохо ли писать:
if (b == false) //...
while (b != true) //...
Всегда лучше писать:
if (!b) //...
while (!b) //...
Предположительно, нет никакой разницы в производительности (или есть?), но как вы взвешиваете объяснительность, краткость, ясность, читаемость и т.д. между ними?
Update
Чтобы ограничить субъективность, я также ценю любые цитаты из авторитетных правил стиля кодирования, которые всегда предпочтительнее или которые следует использовать, когда.
Примечание: имя переменной b используется как пример, ala foo и bar.
Ответ 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: когда кто-то пишет это, он, вероятно, понимает, что происходит.
Я считаю, что это заставило разницу считать более важной, чем она есть на самом деле.
