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) {


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


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


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

if (thudable) {

or any other preferences?

6 Answers 6


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()) { ... }
  • 4
    scrolling to the side vs vertical is not nearly the limitation it was in the bad old days...
    – Bill
    Commented Sep 14, 2010 at 5:48
  • 2
    and give a meaningfull (business) name to the function so that people understand what's tested here. Commented Oct 14, 2010 at 17:46
  • Wow! this solution is so clean. Thanks!
    – Harshit
    Commented Mar 29, 2023 at 9:05

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 &&
  • 1
    I think I like this one. I employ a lot of parenthesis to ensure I can understand the order of precedence too.
    – Jasarien
    Commented Sep 14, 2010 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.
    – user22815
    Commented Apr 25, 2014 at 18:02
  • gofmt moves the { up, which results in less readable code
    – Chris
    Commented Dec 14, 2020 at 19:45

I am a big fan of meaningful variable names:

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

if (isInAStrangeCondition) {

Or refactor as a function, as mentioned above.

  • +1 This answer is analogous to the accepted one, but uses a local variable, which might be preferred in many cases over a new function.
    – 01es
    Commented Jan 19 at 3:27

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.


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'.

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

I'm a fan of the following:

if (really_long_expression && another_really_really_long_expression && 

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.

  • 1
    I really liked your bugs() method :D Commented Nov 5, 2018 at 22:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.