forma más legible para dar formato a largo si las condiciones? [cerrado]

Question

Durante mucho tiempo sinuoso condiciones if se debe evitar si es posible, sin embargo, a veces todos ellos terminan escribiendo. Incluso si es una condición muy simple, los estados implicados son a veces simplemente muy prolijo, lo que la condición enteros termina siendo muy largo. ¿Cuál es la forma más legible para dar formato a los?

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 cualquier otra preferencia?

Answer 1

A menudo, mucho si la condición es el signo de código que refactorización necesidades, pero a veces no pueden evitarlo. En esos casos, prefiero la primera:

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

Debido a que usted es capaz de decir lo que está pasando con una línea. Sin embargo, yo preferiría hacer algo como esto, cuando sea posible:

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

if (foo()) { ... }

Answer 2

I como el mantenimiento de los operadores en el extremo para indicar 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();
}

Answer 3

Soy un gran fan de los nombres de las variables significativas:

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

if (isInAStrangeCondition) {
    thud();
}

O refactor como una función, como se ha mencionado anteriormente.

Answer 4

Me romper las subexpresiones más sucios, o todos ellos, como variables bool. Entonces la lógica booleana de nivel superior de la sentencia 'if' se puede aclarar. En el tipo de trabajo que hago, no es siempre varias cosas OR lógica o unidos mediante AND.

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 mirar a todos los Bools antes de ejecutar el 'si'.

Answer 5

Me tienden a alinearse a los operadores en el inicio de nuevas líneas de modo que recuerdo cómo estoy combinando términos (tanto para la lógica de largo y largo aritmética). De esta manera:

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

Esto sólo funciona si sangría 2-espacios o conjunto establecido mi entorno a los predicados de varias líneas de sangría más, o de lo contrario sería difícil decir dónde comienza los extremos predicados y el código útil.

Answer 6

Soy un fan de los siguientes:

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 una expresión if averiado a pedazos. La muesca ayuda a demostrar que es una continuación de la línea anterior.

También puede sangrar hasta que el corchete de apertura se encuentra al final de la línea anterior para que sea al final de la expresión if como se supone que debe ser.