Asignación booleana de mejores prácticas [cerrada]

Encontré el siguiente condicional en un programa que he adquirido de otro desarrollador:

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.NeedsChange = false;
}

Creo que este código es redundante y feo, así que lo cambié a lo que pensé que era una asignación booleana simple basada en una comparación:

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE;

Al ver esto, alguien revisando mi código comentó que aunque mi cambio es funcionalmente correcto, podría confundir a alguien más que lo mira. Él cree que el uso de un operador ternario hace que esta asignación sea más clara, mientras que no me gusta agregar más código redundante:

obj.NeedsChange = (obj.Performance <= LOW_PERFORMANCE) ? true : false;

Su razonamiento es que hacer algo de la manera más concisa no vale la pena, si hace que otro desarrollador tenga que detenerse y descifrar exactamente lo que has hecho.

La verdadera pregunta aquí es cuál de estos tres métodos para asignar un valor al booleano obj.NeedsChangees el más claro y el más fácil de mantener.

Prefiero 2, pero podría hacer un pequeño ajuste:

obj.NeedsChange = ( obj.Performance <= LOW_PERFORMANCE );

Para mí, los paréntesis hacen que la línea sea más fácil de analizar y deja en claro de un vistazo que está asignando el resultado de una comparación y no está realizando una doble asignación. No estoy seguro de por qué (como fuera de lugar, no puedo pensar en un lenguaje en el que los paréntesis realmente eviten una doble asignación), pero si debe satisfacer a su revisor, entonces quizás esto sea un compromiso aceptable.

La variante 1 se entiende fácilmente, pero esa es su única ventaja. Asumo automáticamente que cualquiera que escriba de esta manera no entiende realmente de qué se tratan los booleanos y escribirá un código infantil similar en muchos otros aspectos.

La variante 2 es lo que siempre escribiría y esperaría leer. Creo que cualquiera que esté confundido por ese idioma no debería ser un escritor profesional de software.

La variante 3 combina las desventajas de ambos 1 y 2. 'dijo nuff.

Cada vez que el código es más complicado de lo que necesita, se desencadena un "¿qué se supone que está haciendo?" huele en el lector.

Por ejemplo, el primer ejemplo me hace preguntarme: "¿hubo alguna otra funcionalidad en la instrucción if / else en algún momento que se eliminó?"

El ejemplo (2) es simple, claro y hace exactamente lo que se necesita. Lo leo e inmediatamente entiendo lo que hace el código.

La pelusa adicional en (3) me haría preguntarme por qué el autor lo escribió de esa manera en lugar de (2). No debería ser una razón, pero en este caso no parece ser, así que no es útil en absoluto y más difícil de leer porque la sintaxis sugiere algo presente que no está allí. Intentar aprender lo que está presente (cuando no hay nada) hace que el código sea más difícil de leer.

Es fácil ver que la Variante 2 y la Variante 1 están relacionadas a través de una serie de refactorizaciones obvias y simples:

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.NeedsChange = false;
}

Aquí, tenemos una duplicación de código innecesaria, podemos factorizar la asignación:

obj.NeedsChange = if (obj.Performance <= LOW_PERFORMANCE)
{
    true
}
else
{
    false
}

o escrito de manera más concisa:

obj.NeedsChange = if (obj.Performance <= LOW_PERFORMANCE) true else false

Ahora, debería ser inmediatamente obvio que esto asignará verdadero si la condición es verdadera y asignará falso si la condición es falsa, IOW simplemente asignará el valor de la condición, es decir, es equivalente a

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE

Las variantes 1 y 3 son códigos de novatos típicos escritos por alguien que no entiende cuál es el valor de retorno de una comparación.

Mientras que su programación debe tender hacia explícito sobre implícita "como si el tipo que termina el mantenimiento de su código será un psicópata violento que sabe dónde vive", que puede asumir algunas cosas básicas que su sucesor será psico competente.

Una de ellas es la sintaxis del lenguaje que está usando.

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE;

es muy claro para cualquiera que conozca la sintaxis de C / C ++ / C # / Java / Javascript.

También es mucho más legible que 8 líneas.

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.NeedsChange = false;
}

y menos propenso a errores

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.Needschange = false;
}

Y es mejor que agregar caracteres innecesarios, como si medio olvidara la sintaxis del idioma:

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE ? true : false;

obj.NeedsChange = (obj.Performance <= LOW_PERFORMANCE);

Creo que hay mucho error sobre la sintaxis tipo C de muchos lenguajes: orden de operaciones inconsistente, asociatividad izquierda / derecha inconsistente, usos sobrecargados de símbolos, llaves / duplicación de sangría, operadores ternarios, notación infija, etc.

Pero la solución no es inventar su propia versión propietaria. De esa manera se encuentra la locura, ya que cada uno crea el suyo.

En general, la cosa número 1 que hace que el código Real World ^{TM sea} ilegible es su cantidad.

Entre un programa de 200 líneas no patológico y un programa de 1,600 líneas trivialmente idéntico, el más corto casi siempre será más fácil de analizar y comprender. Agradecería su cambio cualquier día.

La mayoría de los desarrolladores podrán comprender la segunda forma con un vistazo. En mi opinión, la simplificación como en la primera forma es simplemente innecesaria.

Puede mejorar la legibilidad agregando espacios y llaves como:

obj.NeedsChange =    obj.Performance <= LOW_PERFORMANCE;

o

obj.NeedsChange = ( obj.Performance <= LOW_PERFORMANCE );

como lo mencionó Jacob Raihle.