1TBS for long conditional expressions

Question

Important note: this question is not about the superiority of a bracing style above another. I am currently switching styles in order to evaluate for myself which one I think works best in my situation, and I like Allman as much as 1TBS.

Users of 1TBS bracing style, how do you format long conditions in an if statement and the subsequent code?

if ((this_is_the_first_part_of_a_long_condition)
    && (the_second_part_is_shorter__wait_no_it_is_not)
    && (and_one_more_for_the_road)) {
    here_comes_the_block_code();
}

I feel that there must be a better way. My current way is to add an empty line before the first line of the code block. Allman does not look very good in this case either, although more readable in my opinion.

Another example with for loops:

for (int relevant_counter_variable_name = START_VALUE;
    intelligent_expression_that_may_include_the_counter_variable;
    relevant_counter_variable_update) {
    first_code_line_inside_the_block();
}

Not so nice...

KNF (8 spaces indent) would help here, but I would like to avoid that. I have a couple other options, but I'd like to hear if there is some kind of standard way.

This is exactly the case where I temporarily switch to Allman style, and put the opening brace on its own line aligned with the closing brace. There are those who will shriek and gibber about "mixing styles," but I think it makes for readable code. (The last rule of George Orwell's guide to clear writing is "break any of these rules rather than say something outright barbarous.") Can you say why you think "it does not look very good"? — librik, Mar 29 '11 at 08:52
@librik: although the start of the block (opening brace) is not really a part of the `if`, I like the fact that Allman places it right under the first character of the keyword. My eye puts them together, and does it very fast. If the condition stretches through several lines, the `if` and the `{` look separated and I can hear them cry. Seriously, it just does not look as obvious that they are in the same column. — Gauthier, Mar 29 '11 at 08:58
I'm with librik here - it is more important to make the code readable than to mechanically follow a style. You have found cases where the "rule" perhaps should be seen as a recommendation - follow your preferred style, except when it doesn't work. Personally I follow the Allman style all the time, and haven't run into this. :-) — Bo Persson, Mar 29 '11 at 09:13
BTW, your long condition can be fixed with some refactoring `if (is_some_condition(x,y,z)) {` etc. — Bo Persson, Mar 29 '11 at 09:17
@Bo: you are correct about the refactoring, although I usually have quite long variable names. This kind of refactoring is not always enough, for example when the `if` is on the second level of indentation and I have three conditions with variable names of 15 characters or more. — Gauthier, Mar 29 '11 at 09:27

jhenninger · Answer 1 · 2014-06-14T22:03:15.410

9

I double-indent continued lines:

if ((this_is_the_first_part_of_a_long_condition)
        && (the_second_part_is_shorter__wait_no_it_is_not)
        && (and_one_more_for_the_road)) {
    here_comes_the_block_code();
}

edited Jun 14 '14 at 22:03

answered Sep 07 '12 at 13:13

jhenninger

687
7
12

score 9 · Accepted Answer · answered May 09 '11 at 11:02

9

if (
    (this_is_the_first_part_of_a_long_condition)
    && (the_second_part_is_shorter__wait_no_it_is_not)
    && (and_one_more_for_the_road)
) {
    here_comes_the_block_code();
}

answered May 09 '11 at 11:02

Paul Crowley

1,656
1
14
26

1

This is actually how I tend to do it. – Gauthier May 09 '11 at 14:39

Jens · Answer 3 · 2015-08-05T16:53:23.087

I'd simply waste a few variables for absolute clarity and readability:

cond1 = this_is_the_first_part_of_a_long_condition;
cond2 = the_second_part_is_shorter__wait_no_it_is_not;
cond3 = and_one_more_for_the_road;
if (cond1 && cond2 && cond3) {
    here_comes_the_block_code();
}

There! 1TBS in all its glory. No style mixing. No ugliness. Indent(1) can deal with it without /* *INDENT-OFF* */ cheating.

You could even give the conditions meaningful names, such as

guidance = this_is_the_first_part_of_a_long_condition;
navigation = the_second_part_is_shorter__wait_no_it_is_not;
surgeon = and_one_more_for_the_road;
if (guidance && navigation && surgeon) {
    capcom_we_are_go_for_powered_descent();
} else {
    agc_alarm(1202);
}

score 1 · Answer 4 · edited Jun 20 '20 at 09:12

Mix-n-match

I do agree that mixing styles is often frowned upon.
But, i dare say that where possible, the rule can be bent for readability.

In cases where the style is strictly enforced, (company coding-policies)
I usually do this:

if (  (this_is_the_first_part_of_a_long_condition) &&    
      (the_second_part_is_shorter__wait_no_it_is_not) &&
      (and_one_more_for_the_road)) {
                here_comes_the_block_code();  
}

Just use one-level of indents for all the conditions,
and another additional level for the code inside the braces.
This is as readable as it gets, without offending any purists.

ewd · Answer 5 · 2015-08-05T13:16:57.697

Single space indenting for each level, use parentheses for each condition whether needed or not.

For complicated conditions Allman-style parentheses can work well.

General approach works for continuation of code that won't fit on one line, or for lists of function arguments.

Each closing element is indented at same level as the opening element, hence the "));" for "Trace.WriteLine(String.Format(" and the freestanding ";" for "return".

YMMV.

   if (
    (
     (this_is_the_first_part_of_a_long_condition) && 
     (the_second_part_is_shorter__wait_no_it_is_not) && 
     (and_one_more_for_the_road) 
    ) ||
    (
     (this_is_the_first_part_yet_another) && 
     (
      (the_second_part_yet_another) ||
      (val < 22)
     )
    )
   ) {
      here_comes_the_block_code();

      int bits = 0
       | O_DEF
       | CONFIG_THIS
       | CONFIG_THAT
      ;

      FILE *OUPT = fopen(
       "/tmp/oupt.txt",
       "a+"
      );

      Trace.WriteLine(String.Format(
       "format {0} 0x{1:x8}"
       ,(eGenericDeviceFeatureEnum)val
       ,val & 0x7ffffc00
      ));

      return
       (CurrentWort != null) &&
       (CurrentWort.IsFeatureSupported(
        eGenericDeviceFeatureEnum.SupportsTriBromoCarcinogen
       ))
      ;
   }

1TBS for long conditional expressions

5 Answers5

Mix-n-match