¿Qué es más fácil de mantener: asignación booleana a través de if / else o expresión booleana?

11

¿Cuál se consideraría más mantenible?

if (a == b) c = true; else c = false;

o

 c = (a == b);

He intentado buscar en Code Complete, pero no puedo encontrar una respuesta.

Creo que el primero es más legible (literalmente puedes leerlo en voz alta), lo que también creo que lo hace más fácil de mantener. El segundo ciertamente tiene más sentido y reduce el código, pero no estoy seguro de que sea tan fácil de mantener para los desarrolladores de C # (esperaría ver más este modismo en, por ejemplo, Python).

— Bret Walker
fuente

3

Los dos no son equivalentes. Necesita un else c = falsepara el primero o hacer la asignación un ||=en el segundo.

17

¡Creo que el hecho de que haya tenido que hacer dos ediciones en el primer formulario responde a su pregunta!

— James

77

Estoy de acuerdo con @James. La segunda forma, aunque no es tan detallada, es muy sencilla de entender y no deja ambigüedad en cuanto a su significado. No hay trucos ni atajos, solo es corto porque el concepto es simple. El hecho de que haya codificado el primero con un error, y haya tenido que editarlo para solucionarlo, y todavía no es perfecto (uso inconsistente de llaves), es una prueba positiva de que no es tan sencillo como cree.

— Eric King

55

Wow, ¿los desarrolladores de C # realmente consideran aceptable la primera forma? Esto ... reduce seriamente mi confianza en ellos. En mi experiencia, el uso de la primera forma sugiere en gran medida un completo malentendido de las expresiones booleanas.

— Andres F.

2

Solo para mantener las cosas interesantes, aquí hay otra opción:c = a==b ? true : false;

— FrustratedWithFormsDesigner

14

La segunda opción es mejor.

Hay una razón definitiva para desconfiar de los atajos de programación inteligentes que perjudican el mantenimiento al ocultar la intención del código. Entonces, no te culpo por hacer la pregunta.

Sin embargo, no considero c = (a == b);que sea un ejemplo de un truco inteligente. Es una representación directa de un concepto simple. Tan sencillo como puedas.

Una adecuada, "mantenible" formato del primer ejemplo (sin las llaves que faltan y construcción de una línea, que yo hago considerar un atajo inteligente) produciría este código:

if (a == b)
{
    c = true; 
}
else 
{
    c = false;
}

En mi experiencia, escribir una lógica booleana simple en una forma tan propensa a errores es un signo de código "dudoso". Me haría preguntarme cómo se maneja una lógica más compleja en esta base de código.

— Eric King
fuente

15

Primero, tenga en cuenta que sus dos formas no son equivalentes.

if (a == b) c = true;

cse establecerá en verdadero si aes igual a b, y si no, su valor seguirá siendo lo que sea.

c = (a == b);

cse establecerá en verdadero si aes igual a b, y si no, se establecerá en falso.

Si desea el equivalente de la segunda forma, en el estilo de la primera forma, debe escribirlo así:

if (a == b) {
  c = true;
} else c = false;

Ahora está claro cuál de los dos es más legible, más fácil de mantener y menos propenso a introducir errores si se cambia algo. Quédate con la segunda forma.

— Mason Wheeler
fuente

Absolutamente correcto. He actualizado mi pregunta.

— Bret Walker

Considero que la segunda forma es demasiado larga y complicada: si desea ese efecto, use una asignación booleana.

— Restablecer Monica - M. Schröder

11

No estoy de acuerdo con que su primer formulario sea más legible: ciertamente no es idiomático C # tener dos declaraciones en una sola línea, y no se recomienda tener una ifdeclaración sin usar llaves.

En segundo lugar, no veo cómo la segunda forma es menos mantenible: no hay nada que mantener. Es una simple declaración de la relación entre ay by no podría expresarse más sencillamente.

Otra razón para preferir la segunda forma es que puede declararla cy asignarla en una sola declaración, es decir

bool c = (a == b);

Modificar variables fácilmente puede conducir a errores, por lo que lo evitaría. El uso de una ifdeclaración requiere que la variable se declare antes del condicional y luego se modifique.

— Sotavento
fuente

Leí las dos declaraciones en una línea como pseudocódigo

— Jimmy Hoffa, el

1

+1 para " Another reason to prefer the second form is that you can declare c and assign it in a single statement"

— Andres F.

0

"más mantenible" podría ser muy subjetivo.

Por lo general, prefiero la legibilidad y la intención sobre la reducción de código. Creo que guarda 8 caracteres escritos usando la forma reducida.

Tomar el idioma y la cultura alrededor del idioma es una característica de 'legibilidad' en mi opinión.

Hay momentos en que el rendimiento puede ser la causa de la reducción del código para optimizar el código de bytes resultante, pero eso debe hacerse con cuidado después de algunos perfiles.

— Johnnie
fuente

Subjetivo: Duh. Reducción de código: también puede (si no exagerado) mejorar la claridad y comunicar mejor la intención. Rendimiento: no importa en absoluto (la optimización a veces es vital, pero esto no es algo que caiga bajo optimización, porque prácticamente nunca importa, probablemente ni siquiera si está escribiendo núcleos o controladores).

44

La primera forma tenía al menos 1 error que necesitaba ser corregido, oculto en su verbosidad. La segunda forma era simple y al grano, y no tenía errores. Yo descanso mi caso. En cualquier caso, ¡el propósito principal no era escribir menos caracteres! Y esta pregunta no era sobre el rendimiento, lo cual es irrelevante en este caso.

— Andres F.

@delnan exactamente mi punto, Duh. La reducción del código de alguien es la claridad de otra persona. No mencioné la optimización como la principal preocupación ... Lo usé como ejemplo. Su razón para agregar trucos inteligentes o salir de la norma debe estar equilibrada por lo que usted / cultura / empresa considere legible.

— Johnnie

1

¡Escribir una expresión booleana limpia no es un truco inteligente!

— Andres F.

Supongo que pondría más mérito en su comentario si realmente abordara el espíritu de la pregunta y no una analogía absurda utilizada para apuntalar un concepto subyacente.

— Johnnie

0

El segundo. Tiene menos de repetición (DRY) y es más fácil de entender lo que está pasando, que cmantiene al valor de si o no ay estar bson iguales.

En mi humilde opinión, aún mejor sería

c = a == b

Justo como escribiría

1 + 2 + 3 en vez de ((1 + 2) + 3)
5 + 3 * 7 en vez de (5 + (3 * 7))

Obviamente y el código trivialmente innecesario no es una virtud. Está abarrotado.

— Paul Draper
fuente

-4

Votantes bajos, por favor explique qué está mal con mi respuesta revisada.

Sí, c = (a == b);puede ser difícil de leer (peor aún, StyleCop se queja del paréntesis innecesario), pero todavía me gusta la simplicidad de a == b. Por lo tanto, esto es lo que me gusta usar cuando ambos ay bson los mismos:

private static bool NoPeriod
{
    get
    {
        return this.MyWaveLength == this.HerWaveLength;
    }
}

Y luego puedes hacer: en this.c = this.NoPeriodlugar de:

this.c = this.MyWavelength == this.HerWaveLength;

— Trabajo
fuente

1

Entonces, ¿querías decir return this.MyWaveLength = this.HerWaveLength;o en su return this.MyWaveLength == this.HerWaveLength;lugar?

— Jesse C. Slicer

55

¿¡Qué!? c = (a == b);No es propenso a errores. ¡La primera forma en la pregunta original es mucho más propensa a errores , como lo demuestra el OP mismo que tiene que editar su pregunta para corregir errores!

— Andres F.

Supongo que su solución sugerida tiene un error = vs. ==

— Ondra

@Ondra Morský, gracias ... el compilador habría captado esto por mí.

— Trabajo

66

No estoy familiarizado con StyleCop, pero si te dice que los paréntesis innecesarios son malos, deberías desactivarlo. Los paréntesis innecesarios no son necesarios para el compilador, pero pueden ser muy, muy agradables para los ojos humanos. Si escribiste c = a == b; el compilador puede resolverlo bien, pero es más difícil para un humano.

— Michael Shaw