La plupart de façon lisible format long si les conditions? [fermé]

Question

sinueux conditions if doit être évitée, si possible, mais parfois nous avons tous finissent de les écrire. Même si elle est une condition très simple, les déclarations en cause sont parfois simplement très verbeux, donc l'ensemble des extrémités de l'état jusqu'à être très long. Quelle est la façon la plus lisible pour formater les?

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

ou

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

ou

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

ou

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

if (thudable) {
    thud();
}

ou toute autre préférence?

Answer 1

Souvent, une longue si la condition est le signe de code qui doit refactoring, mais parfois vous ne pouvez pas l'éviter. Dans ce cas, je préfère le premier:

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

Parce que vous êtes en mesure de dire ce qui se passe avec une ligne. Cependant, je ferais bien plutôt quelque chose comme ça, si possible:

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

if (foo()) { ... }

Answer 2

Je aime garder les opérateurs à la fin pour indiquer la continuation:

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

Je suis un grand fan des noms de variables significatives:

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

if (isInAStrangeCondition) {
    thud();
}

Ou refactor en fonction, comme mentionné ci-dessus.

Answer 4

Je casse les malpropres sous-expressions, ou tous, en tant que variables booléens. Ensuite, la logique booléenne niveau supérieur de « si » la déclaration peut être claire. Dans le genre de travail que je fais, ce n'est pas toujours plusieurs choses ORED ou ANDED.

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

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

Ceci est particulièrement bon dans un débogueur, où je peux regarder tous les bools avant d'exécuter le « si ».

Answer 5

J'ai tendance à aligner les opérateurs au début de nouvelles lignes si je me souviens comment je combiner les termes (à la fois pour la logique à long et à long arithmétique). Comme ceci:

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

Cela ne fonctionne que si j'indenter 2-espaces ou un ensemble défini mon environnement à prédicats tiret multilignes plus, ou bien il serait difficile de dire où les extrémités prédicats et le code utile commence.

Answer 6

Je suis fan de ce qui suit:

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

De cette façon, il ressemble toujours à une expression si et non une panne à pièces si l'expression. L'indentation aide à montrer qu'il est une continuation de la ligne précédente.

Vous pouvez également indenter jusqu'à ce que le support d'ouverture est à la fin de la ligne précédente afin qu'il soit à la fin de l'expression if comme il est censé être.