¿La forma más legible de formatear durante mucho tiempo si las condiciones? [cerrado]

38

Las condiciones de bobina larga if deben evitarse en la medida de lo posible, pero a veces todos terminamos escribiendolas. Incluso si es una condición muy simple, las declaraciones involucradas a veces son simplemente muy verbales, por lo que toda la condición termina siendo muy larga. ¿Cuál es la forma más legible de formatear esos?

if (FoobarBaz::quxQuux(corge, grault) || !garply(waldo) || fred(plugh) !== xyzzy) {
    thud();
}

o

if (
    FoobarBaz::quxQuux(corge, grault)
 || !garply(waldo)
 || fred(plugh) !== xyzzy
) {
    thud();
}

o

if (FoobarBaz::quxQuux(corge, grault)
    || !garply(waldo)
    || fred(plugh) !== xyzzy) {
    thud();
}

o

thudable = FoobarBaz::quxQuux(corge, grault);
thudable ||= !garply(waldo);
thudable ||= fred(plugh) !== xyzzy;

if (thudable) {
    thud();
}

o alguna otra preferencia?

    
pregunta deceze 14.09.2010 - 07:23

6 respuestas

28

A menudo, una condición larga es el signo de código que necesita refactorización, pero a veces no se puede evitar. En esos casos, prefiero el primero:

if (bar || baz || quux) { ... }

Porque puedes decir lo que está pasando con una línea. Sin embargo, preferiría hacer algo como esto, cuando sea posible:

function foo() {
  return bar || baz || quux;
}

if (foo()) { ... }
    
respondido por el user8 14.09.2010 - 07:27
16

Me gusta mantener los operadores al final para indicar la continuación:

if (the_function_being_called() != RETURNCODE_SUCCESS &&
    the_possibly_useful_recovery_strategy() == RETURNCODE_EPICFAIL &&
    this_user_has_elected_to_recieve_error_reports)
{
    report_error();
}
    
respondido por el AShelly 14.09.2010 - 07:53
9

Soy un gran fanático de los nombres de variables significativas:

const bool isInAStrangeCondition =
    FoobarBaz::quxQuux(corge, grault) ||
    !garply(waldo) ||
    fred(plugh) !== xyzzy;

if (isInAStrangeCondition) {
    thud();
}

O refactorizar como una función, como se mencionó anteriormente.

    
respondido por el LennyProgrammers 14.09.2010 - 08:44
7

Rompo las subexpresiones más desordenadas, o todas ellas, como variables bool. Luego, se puede aclarar la lógica booleana de nivel superior de la declaración 'if'. En el tipo de trabajo que hago, no siempre hay varias cosas ORed o ANDed.

bool goodblah = some_mess < whatever;
bool frobnacious = messy_crud != junky_expression;
bool yetanother = long_winded_condition;

if (goodblah || (frobnacious && yetanother))   {
    ...
}

Esto es especialmente bueno en un depurador, donde puedo ver todos los bools antes de ejecutar el 'si'.

    
respondido por el DarenW 14.10.2010 - 18:28
6

Tiendo a alinear los operadores al inicio de nuevas líneas, así que recuerdo cómo estoy combinando términos (tanto para lógica larga como para aritmética larga). Así:

if (first_attempt(data) == SUCCESS
    || (reusable(data) && second_attempt(data) == SUCCESS)
    || (still_reusable(data) && third_attempt(data) == SUCCESS))
  return SUCCESS;

Esto solo funciona si indento por 2 espacios o si configuro mi entorno para sangrar más los predicados de varias líneas, o de lo contrario sería difícil saber dónde termina el predicado y comienza el código útil.

    
respondido por el Hoa Long Tam 14.09.2010 - 08:33
0

Soy fanático de lo siguiente:

if (really_long_expression && another_really_really_long_expression && 
            another_very_long_expression_OMG_id_it_long){
    bugs();
}

De esta manera, todavía se ve como una expresión if y no como una expresión descompuesta en partes. La sangría ayuda a mostrar que es una continuación de la línea anterior.

También puedes sangrarlo hasta que el corchete de apertura esté al final de la línea anterior, de modo que esté al final de la expresión if como se supone que debe ser.

    
respondido por el EpsilonVector 14.09.2010 - 07:39

Lea otras preguntas en las etiquetas