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