Most readable way to format long if conditions?

Question

Long winding if conditions should be avoided if at all possible, yet sometimes we all end up writing them. Even if it's a very simple condition, the involved statements are sometimes simply very wordy, so the whole condition ends up being very lengthy. What's the most readable way to format those?

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

or

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

or

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

or

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

if (thudable) {
    thud();
}

or any other preferences?

score 37 · Accepted Answer · edited Apr 25 '14 at 17:40

37

Often, a long if condition is the sign of code that needs refactoring, but sometimes you can't avoid it. In those cases, I prefer the first:

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

Because you're able to tell what's going on with one line. However, I'd much rather do something like this, when possible:

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

if (foo()) { ... }

edited Apr 25 '14 at 17:40

Dorian

103
4

answered Sep 14 '10 at 05:27

4

scrolling to the side vs vertical is not nearly the limitation it was in the bad old days... – Bill Sep 14 '10 at 05:48
2

and give a meaningfull (business) name to the function so that people understand what's tested here. – Matthieu M. Oct 14 '10 at 17:46
Wow! this solution is so clean. Thanks! – Harshit Mar 29 '23 at 09:05

score 27 · Answer 2 · answered Sep 14 '10 at 05:53

27

I like keeping the operators at the end to indicate 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();
}

answered Sep 14 '10 at 05:53

AShelly

5,793
31
51

1

I think I like this one. I employ a lot of parenthesis to ensure I can understand the order of precedence too. – Jasarien Sep 14 '10 at 13:08
11

I prefer putting the logical operators on the start of the line so as I read a line I can easily see it is part of the conditional and not just a regular line of code. – Apr 25 '14 at 18:02
gofmt moves the { up, which results in less readable code – Chris Dec 14 '20 at 19:45

score 12 · Answer 3 · answered Sep 14 '10 at 06:44

I am a big fan of meaningful variable names:

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

if (isInAStrangeCondition) {
    thud();
}

Or refactor as a function, as mentioned above.

score 10 · Answer 4 · answered Oct 14 '10 at 16:28

10

I break out the messier subexpressions, or all of them, as bool variables. Then the top-level boolean logic of the 'if' statement can be made clear. In the kind of work I do, it's not always several things ORed or ANDed.

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

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

This is especially good in a debugger, where I can look at all the bools before executing the 'if'.

answered Oct 14 '10 at 16:28

DarenW

4,433
3
22
43

I like this as well, but you do lose one benefit: it is no longer possible to short-circuit expensive comparisons anymore. – Apr 25 '14 at 18:03
... And you need to be very good at naming tons of variables all days... – cronvel Aug 30 '18 at 12:01
You could also write the comparisons as lazy evaluating expressions and you wouldn't lose the short-circuit advantage. – Huseyin Yagli Apr 25 '20 at 13:38

score 10 · Answer 5 · answered Sep 14 '10 at 06:33

I tend to align the operators at the start of new lines so I remember how I'm combining terms (both for long logic and long arithmetic). Like this:

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

This only works if I indent by 2-spaces or set set my environment to indent multiline predicates more, or else it would be hard to tell where the predicate ends and useful code begins.

score 0 · Answer 6 · answered Sep 14 '10 at 05:39

I'm a fan of the following:

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

This way it still looks like an if expression and not a broken-down-to-pieces if expression. The indentation helps in showing that it is a continuation of the previous line.

You can also indent it until the opening bracket is at the end of the previous line so that it's at the end of the if expression as it's supposed to be.

I really liked your bugs() method :D – Joe Phillips Nov 05 '18 at 22:20 — Joe Phillips, Nov 05 '18 at 22:20

Most readable way to format long if conditions?

6 Answers6