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.hu...@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/

_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to