Por que usar! Boolean_variable Over boolean_variable == false

Um comentário sobre esta pergunta: Verificando se um método retorna false: atribua resultado à variável temporária ou coloque a invocação do método diretamente em condicional? diz que você deve usar em !booleanvez de boolean == falsetestar condições. Por quê? Para mim boolean == falseé muito mais natural em inglês e é mais explícito. Peço desculpas se isso é apenas uma questão de estilo, mas eu queria saber se havia algum outro motivo para essa preferência de !boolean?

Quando vejo uma frase como if (!lateForMeeting()), li isso como "Se não chegar atrasado para a reunião" , o que é bastante simples de entender, em vez de if (lateForMeeting() == false)ler como "Se o fato de estar atrasado para a reunião for falso " .

Eles têm o mesmo significado, mas o primeiro está mais próximo de como a sentença equivalente em inglês seria construída.

Escrever == falsee == trueé redundante. Também pode ser levado a extremos arbitrários. Se você começar a escrever

if (condition == false) { ... }

Então porque não

if ((condition == false) == true) { ... }

Ou porque não

if ((someExp == anotherExp) == true) { ... }

A moral dessa história é que, se conditionfor uma expressão booleana, você não precisará adicionar == false; !é para isso que serve o operador ;)

Em C e em algumas linguagens similares, comparar expressões booleanas para igualdade falseou trueé um hábito perigoso.

Em C, qualquer expressão escalar (numérica ou ponteiro) pode ser usada em um contexto booleano, por exemplo, como condição de uma ifinstrução. A regra C if (cond)é equivalente a if (cond != 0)- ou seja, zero é falso e qualquer valor diferente de zero é verdadeiro. Se condé do tipo ponteiro, 0é tratado como uma constante de ponteiro nulo; if (ptr)meios if (ptr != NULL).

Isso significa que

if (cond)

e

if (cond == true)

não significa a mesma coisa . O primeiro é verdadeiro se condfor diferente de zero; o segundo é verdadeiro apenas se for igual a true, que em C (se você tiver #include <stdbool.h>) é simplesmente 1.

Por exemplo, a isdigit()função declarada em <ctype.h>retorna um intvalor, 0se o argumento for um dígito, diferente de zero se não for. Pode retornar 42para indicar que a condição é verdadeira. A comparação 42 == truefalhará.

Acontece que esse 0é o único valor considerado falso, portanto, a comparação da igualdade falsefuncionará; if (!cond)e if (cond == false)faça a mesma coisa. Mas se você quiser tirar proveito disso, lembre-se de que comparar com falseestá ok e comparar com truenão. Pior ainda, a comparação com trueo trabalho na maioria das vezes (por exemplo, os operadores de igualdade e relacionais sempre produzem um 0ou outro 1). Isso significa que qualquer bug que você introduz usando isso ainda pode ser difícil de localizar. (Não se preocupe, eles aparecerão assim que você demonstrar o código para um cliente importante.)

C ++ possui regras ligeiramente diferentes; por exemplo, seu booltipo é um pouco mais integrado ao idioma e if (cond)converte condem texto bool. Mas o efeito é (principalmente) o mesmo.

Algumas outras linguagens têm o que se poderia chamar de booleanos mais bem comportados, de modo que cond == truee cond == false(ou seja qual for a sintaxe) seja seguro. Mesmo assim, todas as línguas que eu vi tem um notou !operador; está lá, então você pode usá-lo. Usar, em cond == falsevez de !condou not condnão, na minha opinião, melhora a legibilidade. (É verdade que o !personagem pode ser difícil de ver de relance; às vezes adiciono um espaço após o !para evitar isso.)

E muitas vezes você pode evitar o problema e melhorar a clareza reorganizando o código levemente. Por exemplo, em vez de:

if (!cond) {
    do_this();
}
else {
    do_that();
}

você pode escrever:

if (cond) {
     do_that();
}
else {
    do_this();
}

Isso nem sempre é melhor, mas não custa procurar oportunidades onde está.

Resumo: Em C e C ++, as comparações de igualdade truee falsesão perigosas, excessivamente verbais e de estilo pobre. Em muitos outros idiomas, essas comparações podem não ser perigosas, mas ainda são excessivamente verbosas e de estilo pobre.

Os dois são funcionalmente idênticos, então qual deles usar é uma questão de gosto.

A principal razão que eu uso == falseé que eu acho que !é fácil demais ignorar, ao olhar para o código.

Tendo sido severamente mordido por isso, criei o hábito de deixar bem claro ao testar se é falso.

Se o operador tivesse sido nomeado notcomo em Pascal, não acho que isso se tornaria um problema.

Se condition == falseé realmente "muito mais natural em inglês" para você, devo assumir que você não é um falante nativo. Caso contrário, não posso explicar isso, porque ninguém fala assim:

Se o sol está brilhando, eu fico em casa.

Compare isso com

Se o sol não está brilhando, fico em casa.

Dito isto, concordo que o !caractere único e delgado é facilmente esquecido no código. Por esse motivo, prefiro a palavra-chave notquando suportada pelo idioma. O C ++, por exemplo , permite isso, embora muitos programadores não estejam cientes disso.

Para idiomas que exigem !, coloquei um espaço entre operador e operando. Isso torna muito mais difícil ignorar a negação:

if (! condition) { … }

Observe que todo programador deve traduzir isso automaticamente , sem pensar duas vezes, em "não condicionar" em sua cabeça. Adquirir esse tipo de fluência na leitura de idiomas de código está entre os primeiros passos para se tornar um bom programador.

Quando vejo var == false, sempre me pergunto se varé booleano ou de um tipo lógico com mais de dois valores (com, por exemplo, a maybee an undefinede as truee false, ou algo como os nove valores da IEEE 1164 ).

porque às vezes você pode escrever boolean = false(com os erros óbvios) e false == booleannão parece natural (não importa quão boa seja a prática)

if (!boolean_variable)traduz para if the condition is not true.

if (boolean == false)traduz para if the condition not false is true. Porque essa é a lógica inversa, é mais difícil de entender.

Em compiladores (muito) mais antigos, acredito que eles quebrariam (booleano == false) em duas atribuições de registro e um código de comparação em linguagem de máquina. O primeiro exemplo seria dividido em uma atribuição e um operador NOT. Em termos de desempenho, a operação de comparação levaria vários ciclos de clock, dependendo do tamanho do registro sendo comparado, comparado a um invertido bit a bit (1 clock) e seria mais lenta de executar.

Dito isto, acredito que os compiladores mais recentes acabam com isso, então deve ser bom seguir com eles.

No trabalho, muitas vezes estou lidando com booleanos, que podem ser nulos; portanto, codificarei esse caso como

if (value != null && value == true){
    //do something
}

porque eu pessoalmente sinto que a simetria facilita a leitura. Especialmente se houver outros booleanos sendo testados também.

Eu realmente não me importo de um jeito ou de outro.

Quando você está testando a condição verdadeira, faz sentido fazer exatamente isso if (condition), especialmente quando você aplica a convenção de nomear variáveis ​​booleanas começando com 'is': if (isOpen)é perfeitamente claro e o uso != falseseria redundante.

Para um C / C ++ / Java / etc. programador, o significado do '!' O operador é completamente assimilado, a tal ponto que automaticamente "não" temos em nossas mentes quando o vemos. Então, ter if (!isOpen)é tão claro quanto if (_NOT_ isOpen)para mim. Mas você não está familiarizado o suficiente, com o C / C ++ você pode criar uma macro #define _NOT_ !. Mas confie em mim, depois de alguns anos isso é completamente desnecessário.

Além disso, é sempre preferível testar valores booleanos sem compará-los com literais. Por exemplo, é perigoso testar if (x == true)porque um valor booleano é considerado verdadeiro se não for zero, e o literal verdadeiro possui apenas um valor específico; portanto, x pode ser 'verdadeiro' (ou seja, diferente de zero) e ainda assim a comparação é avaliada como falsa (porque contém 2 e o literal verdadeiro é, digamos, 1.) É claro que isso não se aplica a uma comparação com false, mas se você não o usa ao testar para true, por que usá-lo ao testar para false?

Tamanho importa ;)

Em expressões mistas, é mais fácil ler:

boolean1 = false
boolean2 = true

p ! boolean1 and ! boolean2
p boolean1 == false and boolean2 == false

E especial para o ruby, um exemplo em que há uma grande diferença:

boolean = nil
p ! boolean         #-> true
p boolean == false  #-> false

nulo não é falso, mas também não é verdadeiro.

Baseado na minha experiência e nas respostas da minha pergunta à qual você se vinculou.

Algumas pessoas preferem usar if (condição), pelo motivo que é mais curto para escrever. e para mim, na verdade, faz sentido, por exemplo (! isValidated ()) eu li isso como Não validado. mas, para mim, tudo é baseado em preferências pessoais e depende da estrutura lógica do método isValidated (), se retornar verdadeiro ou falso

Se você nomeou sua variável corretamente, !booleané mais natural. Ele lê como not booleanpara quem é programador suficiente para ler código mentalmente.

Para algumas pessoas, quanto mais cedo um significado for expresso, melhor.

Para as pessoas que têm "se! ..." se compara mais rapidamente com "se ...", então precisam ler toda a condição (que pode ser bem longa, por exemplo (thisThing = thatThing ou algo = a outra coisa) OR ( thinga = thingb e thinga = thingd), etc.) apenas para encontrar o == false no final.

Tendo o! (Na verdade, prefiro não quando o idioma o permite) logo de cara o inglês não é 'não' para essa condição.

Esse problema também leva em consideração o uso untilem idiomas que o suportam, por exemplo, faça 'coisas comuns' até que tudo termine. Como outros dizem, a expressão da linguagem natural é o objetivo. Eu gosto do exemplo "o sol está brilhando" acima.

Outro motivo é que, se você estiver trabalhando em uma base de código que usa vários idiomas, se houver uma maneira idiomática de fazer algo seguro em todos os idiomas, é uma boa idéia fazê-lo dessa maneira em qualquer lugar, para que você forme um bom hábito e são menos propensos a tropeçar.

Não consigo pensar em nenhum lugar que if (!variable)(ou equivalente, if not variabledependendo da sua linguagem) não seja seguro, enquanto, por exemplo, if self.is_ready() == False: ...não é seguro em python se self.is_ready()retornar None, agora ou no futuro, o que seria uma coisa totalmente razoável de fazer. indicar que não estava pronto, pois Noneé tão falsa quanto False.