Hacer un gran negocio de == verdadero?

Hay un colega mío que escribe constantemente:

if (someBool == true)

¡Me saca de quicio! ¿Debo hacer un gran negocio o simplemente dejarlo caer?

Es solo código redundante, no vida o muerte. Sin embargo....

Si sucede mucho, podría ser un problema con cómo someBoolse nombra. Un buen nombre puede contribuir en gran medida a eliminar la necesidad de==true

if(IsSomeCondition)

o

if(hasCondition)

o

if(somethingExists)

por ejemplo.

Cuando veo someBool == true, no puedo evitar sentir que el programador no ha internalizado la idea de la evaluación , que es una deficiencia bastante fundamental.

Sin embargo, mi perspectiva es sesgada porque pasé varios veranos en la universidad enseñando programación a niños, quienes frecuentemente escribían expresiones como esta porque realmente no habían dominado el ejercicio mental de evaluar una expresión. Una vez que asimilaron el concepto, la redundancia se hizo evidente.

Para un programador profesional competente, este no es el caso. Probablemente sea solo un mal hábito que desarrollaron en sus primeros días de programación y nunca temblaron. Pero aún así me asustaría un poco si fuera lo primero que vi hacer a alguien en una entrevista.

Eso también me vuelve loco, pero diría que les menciono la redundancia de manera constructiva y luego la dejo caer si no están de acuerdo.

Alternativamente, puede probar este enfoque:
Usted: ¿Puede comenzar a usar la siguiente convención de código para evaluar booleanos?

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

Ellos: ¿Por qué haríamos eso? La segunda mitad de esa declaración es redundante, siempre se evaluaría como verdadera.

Tú: Por George, tienes razón. Tonto de mí. Vayamos con una versión sin toda la redundancia entonces. ¿Qué tal si?

if (someBool) {}

Creo que, si algo tan trivial es su mayor problema con sus compañeros de trabajo, debería considerarse bastante afortunado.

Definitivamente deberías dejar este mal hábito. Suavemente...

Es fácil olvidar escribir los signos de doble igualdad, convirtiendo el código en:

if (someBool = true)

En C #, por ejemplo, esto solo generará una advertencia, no un error. Entonces, a menos que trate las advertencias como errores, el código se ejecutará, establezca la variable en verdadero y siempre ingrese la condición.

Estoy de acuerdo contigo, pero voy a jugar al abogado del diablo aquí:

Dependiendo del idioma y el nombre de la variable, x == verdadero es apropiado:

Considere la siguiente situación en un lenguaje con tipeo estático y coerción de tipos para tipos integrales:

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

Alguien que lea esta sección del código podría no darse cuenta de inmediato de que actionsAllowed es una variable booleana; también podría ser un número entero, que representa el número de acciones permitidas. Entonces, al agregar == verdadero, queda claro que x es un valor booleano, y no un número entero que se coacciona a un valor booleano:

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

¿Qué pasa con las boletas anulables?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

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

Por lo general, no desea hacer un gran problema con las convenciones de codificación a menos que dicha convención de alguna manera impida el proyecto de manera significativa. He visto muchos argumentos acalorados sobre cosas tan pequeñas como regiones de código y guiones bajos.

Dicho esto, no veo ningún problema == truepara agregar a una declaración condicional. De hecho, tengo la costumbre de usar == falseen lugar de un signo de exclamación principal cuando hago pruebas para detectar condiciones negativas. Creo que es más legible.

Si hay una convención establecida, digo que la sigan a menos que haya una razón para cambiar. Sin embargo, realmente no vale la pena plantear un gran problema.

Ack Soy ese chico La vergüenza, la vergüenza. Así es como aprendí, y así es como "formateo automático" en mi cabeza. La única vez que uso la sintaxis preferida de Joel es cuando la variable bool tiene un prefijo verbal como "es". Necesito el verbo, ya sea "es", "puede", "hizo", o de lo contrario necesito el == para proporcionar el verbo "igual". Puede que nunca rompa ese hábito, así que lo entenderé si no me dices 'hola' en la calle.

recuérdame el "código de locura booleana", es así

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

En lugar de:

 otherBool = !someBool

Personalmente, no me gusta la forma de decir "no" en lenguajes basados ​​en C. Ese pequeño signo de exclamación es demasiado fácil de pasar por alto.

Por eso lo escribo en su totalidad:

if (someCondition == false) {

Después de leer eso por un tiempo, también quiero simetría con

if (someCondition == true) {

Así que considérelo un artefacto de C usando en !lugar de not.

Depende del idioma, pero generalmente es una mala idea ...

En C, nunca hagas esto. Es demasiado fácil encontrar una situación en la que el valor que está probando no sea falso (distinto de cero), pero tampoco sea igual al valor único definido como "verdadero".

En Ruby, haga esto solo si está absolutamente seguro de que desea fallar en todo excepto en el booleano verdadero.

En C ++ y otros lenguajes estáticos con un tipo bool, es redundante y puede provocar errores de programación cuando escribe incorrectamente en =lugar de ==errores de promoción como se menciona en los comentarios.

¿Crees que es malo? Qué tal si:

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

yo prefiero

if (bVal)

o

if (!bVal)

también, pero me temo que mencionarlo molestaría a la gente, así que mi consejo es que lo olviden. ¡Lo siento!

deberías decirle que lo está haciendo mal.

sus

if (true == someBool) {

}

si alguna vez olvida uno = está en grandes problemas en su estilo de escritura.

Qué tal si

if (x == "true")

¿POR QUÉ ES UNA CADENA?

En realidad, si es anulable, sería necesario probar x == verdadero. :)

¡Escribo un código así!

Aquí es por qué:

"if bla == true" se lee como una oración, mientras que "if bla" en muchos casos no. Simplemente suena mal, al LEER el código real.

Además, el compilador advierte sobre las asignaciones en los bloques if, por lo que realmente no hay peligro al usar == verdadero. (confundiéndolo con =)

¿También los tipos que no escriben "== verdadero", usan eso "! ()" Para "== falso"? Lo encuentro realmente feo. Y si usa "== falso", es muy consistente también usar "== verdadero", en lugar de tener dos formas distintas de verificar la verdad.

Recuerde que está trabajando como parte de un equipo, por lo que debe resolver estas cosas juntos. "Jugar bien con los demás" sigue siendo un rasgo de personalidad importante incluso después de la escuela primaria :)

En general, omitirá el '== verdadero', pero no vale la pena ni siquiera un minuto para discutirlo a menos que lo incluya en los estándares de codificación de su equipo.

Si bien estoy de acuerdo como desarrollador principalmente de C #, no puedo decir que este sea siempre el caso. Por ejemplo, en Javascript, el === realizará una fusión de tipos. Asumiendo var x = 3 entonces:

if(x) --> true

mientras

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

Supongo que es diferente a == ya que incluso en JS no usaría if (x == true) sino algo en lo que pensar.

Este tipo de toques en otro punto que ha surgido en mi oficina:

bool b = false;

En C #, bool b; sería suficiente e inicializaría b a falso . Sin embargo, es más explícito escribir la línea anterior y, de todos modos, el compilador debe extraerlo durante la optimización.

Así que supongo que mi punto es que no siempre es tan obvio lo que es y no es una buena práctica y mucho se reduce a la preferencia, así como a las características / peculiaridades del lenguaje.

Ah sí, pero ¿y si la variable es anulable? (bool?)

Algunos lenguajes (C #) requerirán una conversión o comparación con 'verdadero'.

bool? isAccepted = true;

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

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

Los jóvenes conocen las reglas, pero los viejos conocen las excepciones;)

En el último C#caso, si está tratando con un null-able bool, entonces debe:

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.
}

Si tristate no es un problema, generalmente no debería haber una razón para comparar algo con true/ True. Sin embargo, en Pythony en varios otros idiomas, como C/C++puede realizar una ifexpresión no bool. Estos lenguajes tienen reglas únicas para interpretar enteros, punteros, listas, etc. como verdaderos o falsos. En algún momento no quieres eso. Por ejemplo, en este fragmento de Python:

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

Aquí zdebería ser True, pero z2debería ser False. Ahora, un Clojurelenguaje se acerca a esto de otra manera: su andfunción no necesariamente se evalúa como a bool, pero la funciónif puede manejar eso.

Independientemente del idioma, cada vez que te encuentres comparando algo Trueo False, probablemente valga la pena comentarlo.

Tal codificación también me habría molestado antes. Aunque su identificador de ejemplo se llama "someBool", usar ese estilo de codificación inadvertidamente en una variable que no se garantizó que sea booleana podría tener un comportamiento involuntario. Si el valor de "someBool" no es exactamente "verdadero" o "falso", el resultado será falso.

Encontré un error muy sutil el año pasado causado por un estilo de codificación tan difícil de identificar porque los ojos de uno brillan sobre tales construcciones. Uno pensaría: "¿Cómo podría estar mal?" Lo mismo se aplica a expresiones tan bien entendidas como "(var)" o "(! Var)", que las lee o las codifica sin verificar su comportamiento.

Así que introduje un par de estándares de codificación para reducir la existencia de tales errores en la base de código y la probabilidad de que tales errores sutiles se cuelen accidentalmente en algún momento en el futuro.

1. Todas las expresiones deben estar entre paréntesis según su intención.
2. Todas las pruebas booleanas deben expresarse en negativo, como "suchBool! = False".

Al limpiar el código que no se ajusta al nuevo estilo, he identificado y corregido algunas instancias más de errores tan sutiles.

Tuve que usar esto todo el tiempo en ActionScript 2 (ciertamente es un lenguaje muerto), 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)
{
}

Así que casi siempre era mejor ser específico.

Estoy de acuerdo. Es una construcción redundante, especialmente en lenguajes mecanografiados fuertes.

Para agregar otro mal uso de booleanos, he encontrado este tipo de construcción muchas veces en Javascript, (especialmente en algunas funciones de monstruos tipo espagueti, como en más de 100 líneas):

//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 debido a la falta de una definición de tipo estricta en este lenguaje, algunos programadores prefieren no tener que perder el tiempo con los false|undefinedvalores.

Tengo un colega que tendrá un código como este:

if(something == true)

Y luego, para algún tipo de prueba / depuración, deseará no llamar a este bloque, por lo que lo cambiará a:

if(something == true && false)

Y luego ocasionalmente lo cambiará a:

if(false)

Lo peor es que este tipo de depuración se me ha pegado en ocasiones y es realmente malo para que otros desarrolladores lo lean.

Yo diría que la consistencia es el rey en una base de código. Entonces deberías usar el estilo, eso es principalmente usa en su organización. Intente que su estilo preferido forme parte de las pautas oficiales de codificación de la compañía. Si ya está en las pautas, solo sígala.

(Dicho esto, también realmente me molestaría, pero probablemente no lo suficiente como para hacer un gran problema).

Prefiero no colocar el extra == verdadero, pero a veces lo incluyo accidentalmente y no lo noto. Es posible que la persona no se haya dado cuenta y los haya colocado accidentalmente. Vuelvo a leer mi código y a veces me doy cuenta de que coloqué el extra == verdadero, así que elimino ese == verdadero. A veces no me doy cuenta y agradecería a alguien que me dijera que lo coloqué de forma redundante.

qué tal si:

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

Sí, lo he visto.