Faça um grande negócio de == verdadeiro?

Há um colega meu que escreve constantemente:

if (someBool == true)

Me leva até a parede! Devo fazer um grande negócio ou simplesmente largar?

É apenas código redundante, não vida ou morte. Contudo....

Se isso estiver acontecendo muito, pode haver um problema com o someBoolnome. Um bom nome pode contribuir bastante para eliminar a necessidade de==true

if(IsSomeCondition)

ou

if(hasCondition)

ou

if(somethingExists)

por exemplo.

Quando vejo someBool == true, não consigo deixar de sentir que o programador não internalizou a ideia de avaliação , que é uma deficiência bastante fundamental.

No entanto, minha perspectiva é distorcida porque passei vários verões na faculdade ensinando programação para crianças, que frequentemente escreviam expressões como essa porque realmente não dominavam o exercício mental de avaliar uma expressão. Depois que eles adotaram o conceito, a redundância se tornou óbvia.

Para um programador profissional competente, esse provavelmente não é o caso. Provavelmente é apenas um mau hábito que eles desenvolveram nos seus primeiros dias de programação e nunca se abalaram. Mas ainda me assustaria um pouco se fosse a primeira coisa que vi alguém fazer em uma entrevista.

Isso também me deixa louco, mas eu diria que mencione a redundância de uma maneira construtiva e a abandone, mesmo que não concorram.

Como alternativa, você pode tentar esta abordagem:
Você : Você pode começar a usar a seguinte convenção de código para avaliar os booleanos?

if (someBool==true)&&(true==true) {}

Eles: Por que faríamos isso? A segunda metade dessa afirmação é redundante, sempre avaliada como verdadeira.

Você: Por George, você está certo. Eu tolo. Vamos apenas seguir uma versão sem toda redundância. E se?

if (someBool) {}

Penso que, se algo tão trivial é o seu maior problema com seus colegas de trabalho, você deve se considerar bastante sortudo.

Você definitivamente deveria parar com esse mau hábito. Suavemente...

É fácil esquecer de escrever os dois sinais de igual, transformando o código em:

if (someBool = true)

Em C #, por exemplo, isso produzirá apenas um aviso, não um erro. Portanto, a menos que você trate os avisos como erros, o código será executado, defina a variável como true e sempre insira a condição.

Eu concordo com você, mas vou interpretar o advogado do diabo aqui:

Dependendo do idioma e do nome da variável, x == true é apropriado:

Considere a seguinte situação em um idioma com digitação estática e coerção de tipo para tipos integrais:

if (actionsAllowed){
    //do actions, since they are allowed
    //...
}

Alguém que esteja lendo esta seção do código pode não perceber imediatamente que actionsAllowed é uma variável booleana - também pode ser um número inteiro, representando o número de ações permitidas. Portanto, adicionando == true, fica claro que x é um booleano e não um número inteiro sendo coagido a um booleano:

if (actionsAllowed == true){
    //do actions, since they are allowed
    //...
}

E os bools anuláveis?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 

Normalmente, você não deseja fazer um grande acordo com as convenções de codificação, a menos que a convenção esteja de alguma forma impedindo o projeto de maneira significativa. Eu já vi muitos argumentos acalorados escalarem coisas tão pequenas quanto as regiões de código e os principais sublinhados.

Dito isto, não vejo problema em adicionar == truea uma declaração condicional. Por uma questão de fato, eu tenho o hábito de usar, == falseem oposição a um ponto de exclamação principal, ao testar condições negativas. Eu acho que é mais legível.

Se houver uma convenção estabelecida, digo segui-la, a menos que haja motivos para mudar. No entanto, não vale a pena levantar muito.

Ack. Eu sou esse cara. A vergonha, a vergonha. É como eu aprendi, e é como eu "formato automaticamente" na minha cabeça. A única vez em que uso a sintaxe preferida de Joel é quando a variável bool tem um prefixo de verbo como "is". Eu preciso do verbo, seja "is", "can", "did", ou então preciso do == para fornecer o verbo "equals". Talvez eu nunca quebre esse hábito, então vou entender se você não me der um 'oi' na rua.

lembre-me do "código booleano da loucura", é como estes

if(someBool == true)
   otherBool = false;
else
   otherBool = true

Ao invés de:

 otherBool = !someBool

Pessoalmente, não gosto muito da maneira de dizer "não" em idiomas baseados em C. Esse pequeno ponto de exclamação é fácil demais de ignorar.

Por isso, escrevo-o na íntegra:

if (someCondition == false) {

Depois de ler isso por um tempo, quero simetria também com

if (someCondition == true) {

Portanto, considere um artefato de C usando em !vez de not.

Depende do idioma, mas geralmente é uma má ideia ...

Em C, nunca faça isso. É muito fácil encontrar uma situação em que o valor que você está testando não é falso (diferente de zero), mas também não é igual ao valor único definido como "verdadeiro".

No Ruby, faça isso apenas se tiver certeza absoluta de que deseja falhar em tudo, exceto em Boolean true.

No C ++ e em outras linguagens estáticas com um tipo bool, é redundante e pode levar a erros de programação quando você digita incorretamente em =vez de ==ou a erros de promoção, conforme mencionado nos comentários.

Você acha que isso é ruim? E se:

if(someCondition) {
  return true;
} else {
  return false;
}

eu prefiro

if (bVal)

ou

if (!bVal)

também, mas tenho medo de que isso surja irritar as pessoas, então meu conselho é esquecê-lo. Desculpa!

você deve dizer a ele que ele está fazendo errado.

Está

if (true == someBool) {

}

se ele esquecer um = está com um grande problema no estilo de escrever.

E se

if (x == "true")

POR QUE ISSO É UMA CORDA ?!

Na verdade, se for anulável, seria necessário testar x == true. :)

Eu escrevo código assim!

Aqui está o porquê:

"if bla == true" lê como uma frase, enquanto que "if bla" não ocorre em muitos casos. Parece errado, ao ler o código real.

Além disso, o compilador avisa sobre atribuições nos blocos if, portanto, não há realmente nenhum perigo em usar == true. (confundindo com =)

Também os caras que não escrevem "== true" usam esse "! ()" Para "== false"? Eu acho isso muito feio. E se você usar "== false", é muito consistente também usar "== true", em vez de ter duas maneiras distintas de verificar a verdade.

Lembre-se de que você está trabalhando como parte de uma equipe, por isso precisa resolver essas coisas juntos. "Se diverte com os outros" ainda é um importante traço de personalidade, mesmo depois do ensino fundamental :)

Geralmente omitirá o '== true', mas dificilmente vale um minuto para discuti-lo, a menos que você o inclua nos padrões de codificação da sua equipe.

Embora eu concorde como desenvolvedor principalmente de C #, não posso dizer que esse seja sempre o caso. Por exemplo, em Javascript, o === executará coalescência do tipo. Então, assumindo var x = 3 então:

if(x) --> true

enquanto

if (x === true) --> false

Eu acho que é diferente de ==, pois mesmo em JS eu não usaria se (x == true), mas apenas algo para pensar.

Esse tipo de toque em outro ponto que surgiu no meu escritório:

bool b = false;

Em C #, bool b; seria suficiente e inicializaria b para falso . No entanto, é mais explícito escrever a linha acima e, de qualquer forma, deve ser arrancada pelo compilador durante a otimização.

Portanto, acho que meu argumento é que nem sempre é tão óbvio o que é e o que não é uma boa prática, e muito disso se resume à preferência, bem como às características / peculiaridades do idioma.

Ah sim, mas e se a variável for anulável? (bool?)

Alguns idiomas (C #) exigirão e converterão ou serão comparados com 'true'.

bool? isAccepted = true;

if((bool)isAccepted)
{...}

if(isAccepted == true)
{...}

Os jovens conhecem as regras, mas os velhos conhecem as exceções;)

No mais recente C#, se você estiver lidando com um null-able bool, precisará:

bool? x = null;
bool? y = true;
bool? z = false;
if (x == true || y == true || z == true) {
    // That was the only way that is reasonably readable that I know of
    // to accomplish this expression.
}

Se tristate não for um problema, geralmente não deve haver um motivo para comparar algo com true/ True. No entanto, em Pythonvários idiomas, como C/C++você pode executar uma ifexpressão não-booleana. Esses idiomas têm regras exclusivas para interpretar números inteiros, ponteiros, listas etc. como verdadeiros ou falsos. Às vezes você não quer isso. Por exemplo, neste trecho de código Python:

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

Aqui zdeveria estar True, mas z2deveria estar False. Agora, uma Clojurelinguagem aborda isso de outra maneira - a andfunção não necessariamente avalia como a bool, mas ifpode lidar com isso.

Independentemente do idioma, sempre que você se comparar a algo Trueou False, provavelmente vale a pena comentar.

Essa codificação também teria me atrapalhado antes. Embora seu identificador de exemplo seja chamado "someBool", o uso inadvertido desse estilo de codificação em uma variável que não era garantida como booleana pode ter um comportamento não intencional. Se o valor de "someBool" não for exatamente "true" ou "false", o resultado será falso.

Eu encontrei um bug muito sutil no ano passado, causado por um estilo de codificação difícil de identificar, porque os olhos de alguém refletem essas construções. Você pensaria: "Como isso pode estar errado?" O mesmo vale para expressões bem compreendidas como "(var)" ou "(! Var)", que você as lê ou codifica sem verificar o comportamento delas.

Então, eu introduzi alguns padrões de codificação para reduzir a existência de tais erros na base de código e a probabilidade de que esses erros sutis se infiltrem acidentalmente em algum momento no futuro.

1. Todas as expressões devem estar entre parênteses de acordo com sua intenção.
2. Todos os testes booleanos devem ser expressos em negativo, como "suchBool! = False".

Ao limpar o código que não está em conformidade com o novo estilo, identifiquei e corrigi mais algumas instâncias desses erros sutis.

Tinha que usar isso o tempo todo no ActionScript 2 (agora reconhecidamente uma linguagem morta), porque:

var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();

// this is slightly ambiguous
if(something)
{
}

// because if you allow undefined you might actually mean
if(false != something)
{
}

// which can mean something different than
if(true == something)
{
}

// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}

Por isso, quase sempre era melhor ser específico.

Concordo. É uma construção redundante, especialmente em idiomas de tipos fortes.

Para adicionar outro uso indevido de booleanos, eu encontrei esse tipo de construção várias vezes em Javascript (especialmente em algumas funções de monstros semelhantes a espaguetes, como em mais de 100 linhas):

//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example 
flag=$("mycheckbox").selected;
//...

//and at the moment of use it:
if(flag!=true) {
   //code to execute when the checkbox is unchecked
}

Parece que, devido à falta de uma definição estrita de tipo nessa linguagem, alguns programadores preferem não ter que mexer com os false|undefinedvalores.

Eu tenho um colega que terá algum código como este:

if(something == true)

E então, para algum tipo de teste / depuração, ele desejará não chamar esse bloco, então ele mudará para:

if(something == true && false)

E então, ocasionalmente, ele muda para:

if(false)

O pior é que esse tipo de depuração passou para mim de vez em quando e é muito ruim para outros desenvolvedores lerem!

Eu diria que a consistência é o rei em uma base de código. Portanto, você deve usar o estilo, usado principalmente em sua organização. Tente fazer do seu estilo preferido parte das diretrizes oficiais de codificação da empresa. Se já estiver nas diretrizes, basta segui-las.

(Dito isto, também me incomodaria muito - mas provavelmente não o suficiente para fazer um grande negócio com isso).

Prefiro não colocar o extra == true, mas às vezes eu o incluo acidentalmente e não percebo. A pessoa pode não ter percebido e colocado acidentalmente. Reli o meu código e, às vezes, percebo que coloquei o extra == true, então removo o == true. Às vezes, eu não percebo e gostaria de receber alguém que me disse que eu o coloquei de forma redundante.

que tal:

int j = 1;
for (int i=1; i>=j; i++) ...

Sim, eu já vi.