Breaking Long Lines

Sebastian Huber sebastian.huber at embedded-brains.de
Mon Nov 9 06:50:51 UTC 2020


On 09/11/2020 01:52, Chris Johns wrote:

> On 6/11/20 7:11 pm, Sebastian Huber wrote:
>> Hello,
>>
>> for breaking long lines we have currently:
>>
>> "Should be replaced with
>>
>> .. code-block:: c
>>
>>    for (
>>      initialization = statement;
>>      a + really + longish + statement + that + evaluates + to <
>>      a + boolean;
>>      another + statement++
>>    ) {
>>      z = a + really + longish + statement + that + needs +
>>          two + lines + gets + indented + four + more +
>>          spaces + on + the + second + and + subsequent +
>>          lines + and + broken + up + at + operators;
>>    }
>>
>> Note that indentations should add 2 nesting levels (4 space characters, not tabs)."
>>
>> Do we really need two indent levels for breaking long lines in block statements?
>> I would just say that the continuation of a broken line is indented by one
>> level. The example would look like this (please note the change in the for loop
>> "a + boolean"):
>>
>> .. code-block:: c
>>
>>    for (
>>      initialization = statement;
>>      a + really + longish + statement + that + evaluates + to <
>>        a + boolean;
>>      another + statement++
>>    ) {
>>      z = a + really + longish + statement + that + needs +
>>        two + lines + gets + indented + four + more +
>>        spaces + on + the + second + and + subsequent +
>>        lines + and + broken + up + at + operators;
> I sometimes add parentheses to aid indenting:
>
>    z = (a + really + longish + stat
>               ....
>         lines + and + broken + up + at + operators);
>
> Emacs automatically indents to the opening `(`. This is mentioned in the GNU
> coding standard. We however have this statement in our standard ...
>
>   Avoid excess parentheses. Learn the operator precedence. rules.

Yes, and I think this is a good rule.

My question is if we really should indent by two levels for the 
continuation of long lines.

variable = ...

<SP><SP><SP><SP>foo bar continuation ...

vs.

variable = ...

<SP><SP>foo bar continuation ...

I never noticed the first style in the RTEMS sources and was a bit 
surprised of this text.

I also missed the recommendation to place the operators as the last 
token, but I will do this now.

-- 
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/



More information about the devel mailing list