Breaking Long Lines
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;
}
--
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
[PATCH] eng: Move code formatting rules into one section
Clarify the 80 character limit. Change the line continuation indent
level.
---
eng/coding-80cols.rst | 154 -
eng/coding-conventions.rst | 26 -
eng/coding-formatting.rst | 196 +
eng/coding.rst | 2 +-
4 files changed, 197 insertions(+), 181 deletions(-)
delete mode 100644 eng/coding-80cols.rst
create mode 100644 eng/coding-formatting.rst
diff --git a/eng/coding-80cols.rst b/eng/coding-80cols.rst
deleted file mode 100644
index 85b838a..000
--- a/eng/coding-80cols.rst
+++ /dev/null
@@ -1,154 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-4.0
-
-.. Copyright (C) 2018.
-.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
-
-Eighty Character Line Limit
-***
-
-.. COMMENT: TBD - Convert the following to Rest and insert into this file
-.. COMMENT: TBD -
https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line
-
- Code should look good for everyone under some standard width assumptions.
- Where a line wraps should be the same for anyone reading the code. For
- historical reasons, RTEMS uses 80 characters as the maximum width for each
- line of code.
-
-If you find yourself with code longer than 80 characters, first ask yourself
-whether the nesting level is too deep, names too long, compound expressions too
-complicated, or if some other guideline for improving readability can help to
-shrink the line length. Refactoring nested blocks into functions can help to
-alleviate code width problems while improving code readability. Making names
-descriptive yet terse can also improve readability. If absolutely necessary
-to have a long line, follow the rules on this page to break the line up to
adhere
-to the 80 characters per line rule.
-
-Breaking long lines
-
-``if``, ``while``, and ``for`` loops have their condition expressions aligned
-and broken on separate lines. When the conditions have to be broken, none go on
-the first line with the ``if``, ``while``, or ``for`` statement, and none go on
-the last line with the closing parenthesis and (optional) curly brace. Long
-statements are broken up and indented at operators, with an operator always
-being the last token on a line. No blank spaces should be left at the end of
-any line. Here is an example with a ``for`` loop.
-
-.. code-block:: c
-
- for ( initialization = statement; a + really + long + statement + that +
evaluates + to < a + boolean; another + statement++ ) {
-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;
- }
-
-Should be replaced with
-
-.. code-block:: c
-
- for (
-initialization = statement;
-a + really + long + statement + that + evaluates + to <
-a + boolean;
-another + statement++
- ) {
-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;
- }
-
-Note that indentations should add 2 nesting levels (4 space characters, not
tabs).
-
-Similarly,
-
-.. code-block:: c
-
- if ( this + that < those && this + these < that && this + those < these &&
this < those && those < that ) {
-
-should be broken up like
-
-.. code-block:: c
-
- if (
-this + that < those &&
-this + these < that &&
-this + those < these &&
-this < those &&
-those < that
- ) {
-
-Note that each expression that resolves to a boolean goes on its own line.
-Where you place the boolean operator is a matter of choice.
-
-When a line is long because of a comment at the end, move the comment to
-just before the line, for example
-
-.. code-block:: c
-
- #define A_LONG_MACRO_NAME (AND + EXPANSION) /* Plus + a + really + long +
comment */
-
-can be replaced with
-
-.. code-block:: c
-
- /* Plus + a + really + long + comment */
- #define A_LONG_MACRO_NAME (AND + EXPANSION)
-
-C Preprocessor macros need to be broken up with some care, because the
-preprocessor does not understand that it should eat newline characters. So
-
-.. code-block:: c
-
- #define A_LONG_MACRO_NAME (AND + EXCESSIVELY + LONG + EXPANSION + WITH +
LOTS + OF + EXTRA + STUFF + DEFINED)
-
-would become
-
-.. code-block:: c
-
- #define A_LONG_MACRO_NAME ( \
-AND + EXCESSIVELY + LONG + EXPANSION + WITH + LOTS + OF + EXTRA + STUFF + \
-DEFINED \
- )
-
-Notice that each line is terminated by a backslash then the carriage return.
-The backslash tells the preprocessor to eat the newline. Of course, if you have
-such a long macro, you should consider not using a macro.
-
-Function declarations can be broken up at each argument, for example
-
-.. code-block:: c
-
- int this_is_a_function( int arg1, int arg2, int arg3, int arg4, int arg5,
int arg6, int arg7, int arg8, int arg9 );
-
-would be broken up
[PATCH] if_ffec: Fix cache handling on tx.
With the previous fix, it could happen that the end of the packet hasn't been flushed. For example assume the following addresses: ds_addr: 0x81c804A ds_len: 0x57 In that case the data ends at 0x81c80a1. But due to the rounding the area from 0x81c8040 to 0x81c80a0 would have been flushed. This fix now first calculates the start and end address, aligns these addresses and then recalculates the len that has to be flushed. --- freebsd/sys/dev/ffec/if_ffec.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/freebsd/sys/dev/ffec/if_ffec.c b/freebsd/sys/dev/ffec/if_ffec.c index e8287ed2..47c0f770 100644 --- a/freebsd/sys/dev/ffec/if_ffec.c +++ b/freebsd/sys/dev/ffec/if_ffec.c @@ -714,15 +714,16 @@ ffec_encap(struct ifnet *ifp, struct ffec_softc *sc, struct mbuf *m0, tx_desc->buf_paddr = segs[i].ds_addr; tx_desc->flags2 = flags2; #ifdef __rtems__ - uintptr_t addr_flush = (uintptr_t)segs[i].ds_addr; + uintptr_t first_flush = (uintptr_t)segs[i].ds_addr; size_t len_flush = segs[i].ds_len; #ifdef CPU_CACHE_LINE_BYTES + uintptr_t last_flush = first_flush + len_flush; /* mbufs should be cache line aligned. So we can just round. */ - addr_flush = addr_flush & ~(CPU_CACHE_LINE_BYTES - 1); - len_flush = (len_flush + (CPU_CACHE_LINE_BYTES - 1)) & - ~(CPU_CACHE_LINE_BYTES - 1); + first_flush = rounddown2(first_flush, CPU_CACHE_LINE_BYTES); + last_flush = roundup2(last_flush, CPU_CACHE_LINE_BYTES); + len_flush = last_flush - first_flush; #endif - rtems_cache_flush_multiple_data_lines((void*)addr_flush, + rtems_cache_flush_multiple_data_lines((void*)first_flush, len_flush); #endif /* __rtems__ */ -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] eng: Move code formatting rules into one section
Hi Sebastian > + /* > + * Excessively long comments should be broken up at a word boundary or > + * somewhere that makes sense, for example. > + */ > + > +Note that multiline comments have a single asterisk aligned with the asterisk > +in the opening ``/*``. > The closing ``*/`` should go at the end of the last line. I think this is closer to what was discussed earlier: The closing ``*/`` should appear on a line by itself at the end. Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Software Foundations & Verification Research Group School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] eng: Move code formatting rules into one section
On 06/11/2020 10:35, Andrew Butterfield wrote: The closing ``*/`` should appear on a line by itself at the end. Thanks for the review, I changed the patch to use this sentence. -- 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
