É ruim comparar explicitamente com constantes booleanas, por exemplo, if (b == false) em Java?

É ruim escrever:

if (b == false) //... while (b != true) //... 

É sempre melhor escrever em vez disso:

 if (!b) //... while (!b) //... 

Presumivelmente, não há diferença no desempenho (ou existe?), Mas como você pesa a explicitação, a concisão, a clareza, a legibilidade, etc entre os dois?

Atualizar

Para limitar a subjetividade, eu também apreciaria quaisquer citações de diretrizes de estilo de codificação autorizadas sobre as quais é sempre preferível ou que usar quando.


Nota : o nome da variável b é usado apenas como exemplo, ala foo e bar .

Não é necessariamente ruim, é apenas supérfluo. Além disso, o nome real da variável pesa muito. Eu preferiria por exemplo if (userIsAllowedToLogin) acima if (b) ou pior ainda if (flag) .

Quanto à preocupação com o desempenho, o compilador o otimiza de qualquer maneira.

Update : quanto às fonts autorizadas, não consigo encontrar algo explicitamente nas Convenções de codificação da Sun , mas pelo menos o Checkstyle tem um módulo SimplifyBooleanExpression que avisa sobre isso.

Você não deve usar o primeiro estilo. Eu vi pessoas usarem:

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

Eu pessoalmente acho difícil de ler, mas é aceitável. No entanto, um grande problema que tenho com esse estilo é que ele leva aos exemplos incrivelmente contra-intuitivos que você mostrou:

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

Isso exige mais esforço da parte do leitor para determinar a intenção dos autores. Pessoalmente, acho que include uma comparação explícita para true ou false é redundante e, portanto, mais difícil de ler, mas esse sou eu.

Isso é fortemente uma questão de gosto.

Pessoalmente eu encontrei que if (!a) { é muito menos legível (EDIT: para mim) do que if (a == false) { e, portanto, mais propenso a erros ao manter o código mais tarde, e eu converti para usar a última forma.

Basicamente eu não gosto da escolha de símbolos para operações lógicas em vez de palavras (C versus Pascal), porque para mim a = 10 and not b = 20 leituras mais fáceis que a == 10 && !(b==20) , mas essa é a como é em Java.

Qualquer um que coloque a abordagem “== false” em favor de “!” claramente nunca tinha olhado o código por muito tempo e perdido aquele ponto de exclamação. Sim, você pode obter código cego.

A principal razão pela qual você não deve usar o primeiro estilo é porque ambos são válidos:

 if (b = false) //... while (b = true) //... 

Ou seja, se você ignorar acidentalmente um caractere, crie uma atribuição em vez de uma comparação. Uma expressão de atribuição é avaliada para o valor que foi atribuído, portanto, a primeira instrução acima atribui o valor false a b e avalia a false . O segundo atribui true a b , então ele sempre é true , não importa o que você faça com b dentro do loop.

Eu nunca vi o primeiro, exceto em código escrito por iniciantes; é sempre o último, e não acho que alguém esteja realmente confuso com isso. Por outro lado, eu acho

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

vs

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

é muito mais discutível, e nesse caso eu prefiro o segundo

IMHO, eu acho que se você apenas fizer os nomes de variables ​​bool "Is" com "Is" , isso será evidente e mais significativo e, em seguida, você poderá remover a comparação explícita com true ou false

Exemplo:

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

etc

Eu prefiro o primeiro, porque é mais claro. A máquina pode ler igualmente bem, mas eu tento escrever código para outras pessoas lerem, não apenas a máquina.

Eu prefiro a abordagem longa, mas eu comparo usando == vez de != 99% do tempo.

Eu sei que esta questão é sobre Java, mas muitas vezes alternar entre as linguagens, e em C# , por exemplo, comparando com (para isntance) == false pode ajudar quando se lida com tipos de bool anulável. Então eu peguei esse habbit de comparar com true ou false mas usando o operador == .

Eu faço isso:

if(isSomething == false) ou if(isSomething == true)

mas eu odeio estes:

if(isSomething != false) ou if(isSomething != true)

por razões óbvias de legibilidade!

Contanto que você mantenha seu código legível, isso não importará.

Pessoalmente, eu refatoraria o código para não usar um teste negativo. por exemplo.

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

ou

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

IMHO, em 90% dos casos, o código pode ser refatorado, portanto, o teste negativo não é necessário.

Na minha opinião, é simplesmente irritante. Não é algo que eu poderia causar um tumulto embora.

A diretriz normal é nunca testar contra booleanos. Alguns argumentam que a verbosidade adicional aumenta a clareza. O código adicionado pode ajudar algumas pessoas, mas todo leitor precisará ler mais código.

Esta manhã, perdi 1/2 hora para encontrar um bug. O código foi

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

Se fosse codificado com convenção normal, eu teria visto muito mais rápido que estava errado:

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

Esta é a minha primeira resposta no StackOverflow, então seja legal … Recentemente, durante a refatoração, notei que dois blocos de código tinham quase o mesmo código, mas um usado

 for (Alert alert : alerts) { Long currentId = alert.getUserId(); if (vipList.contains(currentId)) { customersToNotify.add(alert); if (customersToNotify.size() == maxAlerts) { break; } } } 

e o outro tinha

 for (Alert alert : alerts) { Long currentId = alert.getUserId(); if (!vipList.contains(currentId)) { customersToNotify.add(alert); if (customersToNotify.size() == maxAlerts) { break; } } } 

Portanto, neste caso, fazia sentido criar um método que funcionasse para ambas as condições, como esta, usando a boolean == condition para inverter o significado.

 private void appendCustomersToNotify(List alerts List customersToNotify, List vipList, boolean vip){ for (Alert alert : alerts) { Long currentId = alertItem.getUserId(); if (vip == vipList.contains(currentId)) { customersToNotify.add(alertItem); if (customersToNotify.size() == maxAlerts) { break; } } } } 

Eu diria que é ruim.

 while (!b) { // do something } 

lê muito melhor do que

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

Uma das razões pelas quais o primeiro (b == false) é desaprovado é que os iniciantes muitas vezes não percebem que a segunda alternativa (! B) é possível. Portanto, usar o primeiro formulário pode apontar para um equívoco com expressões booleanas e variables ​​booleanas. Dessa forma, usar a segunda forma tornou-se um tipo de sjiboleth: quando alguém escreve isso, provavelmente entende o que está acontecendo.

Eu acredito que isso fez com que a diferença fosse considerada mais importante do que realmente é.