<div dir="ltr">I pushed this. If you spot issues anywhere in the conversions, just submit separate patches -- one per file.<div><br></div><div>I will be slow the next few days so make sure things get merged.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 1, 2018 at 11:14 AM Marçal Comajoan Cara <<a href="mailto:mcomajoancara@gmail.com">mcomajoancara@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Converted <a href="https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line</a><br>
to Rest, and TBDs into comments.<br>
<br>
This work was part of GCI 2018.<br>
---<br>
 eng/coding-80cols.rst | 149 +++++++++++++++++++++++++++++++++++++++++-<br>
 1 file changed, 147 insertions(+), 2 deletions(-)<br>
<br>
diff --git a/eng/coding-80cols.rst b/eng/coding-80cols.rst<br>
index 442a9e0..48b2c65 100644<br>
--- a/eng/coding-80cols.rst<br>
+++ b/eng/coding-80cols.rst<br>
@@ -6,5 +6,150 @@<br>
 Eighty Character Line Limit<br>
 ***************************<br>
<br>
-TBD  - Convert the following to Rest and insert into this file<br>
-TBD - <a href="https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line</a><br>
+.. COMMENT: TBD - Convert the following to Rest and insert into this file<br>
+.. COMMENT: TBD - <a href="https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line</a><br>
+<br>
+ Code should look good for everyone under some standard width assumptions.<br>
+ Where a line wraps should be the same for anyone reading the code. For<br>
+ historical reasons, RTEMS uses 80 characters as the maximum width for each<br>
+ line of code.<br>
+<br>
+If you find yourself with code longer than 80 characters, first ask yourself<br>
+whether the nesting level is too deep, names too long, compound expressions too<br>
+complicated, or if some other guideline for improving readability can help to<br>
+shrink the line length. Refactoring nested blocks into functions can help to<br>
+alleviate code width problems while improving code readability. Making names<br>
+descriptive yet terse can also improve readability. If absolutely necessary<br>
+to have a long line, follow the rules on this page to break the line up to adhere<br>
+to the 80 characters per line rule. <br>
+<br>
+Breaking long lines<br>
+-------------------<br>
+<br>
+``if``, ``while``, and ``for`` loops have their condition expressions aligned<br>
+and broken on separate lines. When the conditions have to be broken, none go on<br>
+the first line with the ``if``, ``while``, or ``for`` statement, and none go on<br>
+the last line with the closing parenthesis and (optional) curly brace. Long<br>
+statements are broken up and indented at operators, with an operator always<br>
+being the last token on a line. No blank spaces should be left at the end of<br>
+any line. Here is an example with a ``for`` loop.<br>
+<br>
+.. code-block:: c<br>
+<br>
+  for ( initialization = statement; a + really + long + statement + that + evaluates + to < a + boolean; another + statement++ ) {<br>
+    z = a + really + long + statement + that + needs + two + lines + gets + indented + four + more + spaces + on + the + second + and + subsequent + lines + and + broken + up + at + operators;<br>
+  }<br>
+<br>
+Should be replaced with<br>
+<br>
+.. code-block:: c<br>
+<br>
+  for (<br>
+    initialization = statement;<br>
+    a + really + long + statement + that + evaluates + to <<br>
+    a + boolean;<br>
+    another + statement++<br>
+  ) {<br>
+    z = a + really + long + statement + that + needs +<br>
+        two + lines + gets + indented + four + more +<br>
+        spaces + on + the + second + and + subsequent +<br>
+        lines + and + broken + up + at + operators;<br>
+  }<br>
+<br>
+Note that indentations should add 2 nesting levels (4 space characters, not tabs). <br>
+<br>
+Similarly,<br>
+<br>
+.. code-block:: c<br>
+<br>
+  if ( this + that < those && this + these < that && this + those < these && this < those && those < that ) {<br>
+<br>
+should be broken up like <br>
+<br>
+.. code-block:: c<br>
+<br>
+  if (<br>
+    this + that < those &&<br>
+    this + these < that &&<br>
+    this + those < these &&<br>
+    this < those &&<br>
+    those < that<br>
+  ) {<br>
+<br>
+Note that each expression that resolves to a boolean goes on its own line.<br>
+Where you place the boolean operator is a matter of choice.<br>
+<br>
+When a line is long because of a comment at the end, move the comment to<br>
+just before the line, for example <br>
+<br>
+.. code-block:: c<br>
+<br>
+  #define A_LONG_MACRO_NAME (AND + EXPANSION) /* Plus + a + really + long + comment */<br>
+<br>
+can be replaced with <br>
+<br>
+.. code-block:: c<br>
+<br>
+  /* Plus + a + really + long + comment */<br>
+  #define A_LONG_MACRO_NAME (AND + EXPANSION)<br>
+<br>
+C Preprocessor macros need to be broken up with some care, because the<br>
+preprocessor does not understand that it should eat newline characters. So<br>
+<br>
+.. code-block:: c<br>
+<br>
+  #define A_LONG_MACRO_NAME (AND + EXCESSIVELY + LONG + EXPANSION + WITH + LOTS + OF + EXTRA + STUFF + DEFINED)<br>
+<br>
+would become<br>
+<br>
+.. code-block:: c<br>
+<br>
+  #define A_LONG_MACRO_NAME ( \<br>
+    AND + EXCESSIVELY + LONG + EXPANSION + WITH + LOTS + OF + EXTRA + STUFF + \<br>
+    DEFINED \<br>
+  )<br>
+<br>
+Notice that each line is terminated by a backslash then the carriage return.<br>
+The backslash tells the preprocessor to eat the newline. Of course, if you have<br>
+such a long macro, you should consider not using a macro.<br>
+<br>
+Function declarations can be broken up at each argument, for example<br>
+<br>
+.. code-block:: c<br>
+<br>
+  int this_is_a_function( int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7, int arg8, int arg9 );<br>
+<br>
+would be broken up as<br>
+<br>
+.. code-block:: c<br>
+<br>
+  int this_is_a_function(<br>
+    int arg1,<br>
+    int arg2,<br>
+    int arg3,<br>
+    int arg4,<br>
+    int arg5,<br>
+    int arg6,<br>
+    int arg7,<br>
+    int arg8,<br>
+    int arg9<br>
+  );<br>
+<br>
+Excessively long comments should be broken up at a word boundary or somewhere<br>
+that makes sense, for example<br>
+<br>
+.. code-block:: c<br>
+<br>
+  /* Excessively long comments should be broken up at a word boundary or somewhere that makes sense, for example */<br>
+<br>
+would be<br>
+<br>
+.. code-block:: c<br>
+<br>
+  /* Excessively long comments should be broken up at a word boundary or<br>
+   * somewhere that makes sense, for example */<br>
+<br>
+Note that multiline comments have a single asterisk aligned with the asterisk<br>
+in the opening ``/*``. The closing ``*/`` should go at the end of the last<br>
+line.<br>
+<br>
-- <br>
2.17.1<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div>