Coding Style for RTEMS

Tue Dec 4 13:00:23 UTC 2012

On 12/04/2012 12:31 PM, Gedare Bloom wrote:
>
> While I'm not so sure that having two coding styles is a great idea, I 
> think it will be easiest to maintain the existing "RTEMS Style" in the 
> score. I'd be on-board with adopting the freebsd style guide to fit 
> RTEMS, I think that a codified set of rules will be nice to have. Joel 
> had an Asciidoc floating around that described the RTEMS Style, but it 
> wasn't complete.
>
How incomplete is up for debate. :)

I have attached what I have and there is a Wiki page which
also captures some of the rules.

http://www.rtems.org/wiki/index.php/Coding_Conventions

My cynical view is that no one but me has ever written a line
on Coding Style, there was no auto-reformatting, no way to
reformat non-conformant code, and thus it was easy for
those who didn't like the style to ignore it.

Not picking on Sebastian.. but his editor randomly reformatted
the license text into two lines. I only recently managed to kill
all these.

So my view is that we need to follow the RTEMS style which
was used in the core, tighten it, define it and find tools
which help.

Third party code should NOT NOT NOT be reformatted.

I can put the attached document in git if we want to
commit to actually writing it.

I am also happy to discuss coding standards from NASA, ESA,
JPL, MISRA, etc. but they better make sense for RTEMS and
be enforceable by free tools.
> Some of the BSD rules won't make sense in RTEMS, and some will need to 
> be modified to fit, e.g. "use chains" instead of "use queues", and the 
> API visibility rules.
>
> The RTEMS Style may not be standard, but I don't think it would be 
> hard to codify to apply to all of RTEMS.  Perhaps adopting BSD rules 
> where the RTEMS style is "silent" could help there, but there are 
> conflicts between the BSD and RTEMS style, so merging the two would 
> not be clean.
>
> Rules that conflict explicitly between BSD and RTEMS style include:
> * use of tabs
> * no space after ( and before ) in if/for/etc statements
> * variable declaration name alignment
>
> Points where RTEMS style implicitly conflicts with BSD include:
> * avoid typedefs
> * \ aligned to the far right
> * function type on line before function name
> * variable declarations sorted by size and alphabet
>
> It might also be nice to define rules about assembly, both inline and 
> in .S files.
>
> -Gedare
>
>
> On Tue, Dec 4, 2012 at 12:50 PM, Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>     Hello,
>
>     we need a formal coding style for RTEMS since otherwise it is very
>     hard for newcomers to do things right.  My first question to this
>     topic is this:
>
>     Do we want to use two coding styles? One for the score
>     (cpukit/{score, rtems, posix, sapi}) and one for other parts (like
>     shell, test suite, BSPs, etc.).
>
>     The score has a consistent coding style.  Here we need only a good
>     description.  The bad thing of the score coding style is that it
>     is somewhat special and not in widespread use outside of RTEMS.
>
>     Other parts in RTEMS have no consistent coding style.  I suggest
>     to use a well established coding style for these and enforce it
>     for new files.  Since we already use large parts of BSD (old and
>     new network stack, USB stack, ATA stack) this is a natural choice.
>
>     http://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html
>     <http://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html>
>
>     Another one is the Linux coding style.
>
>     http://www.kernel.org/doc/Documentation/CodingStyle
>
>     For the GNU style let me quote the document above:
>
>     "First off, I'd suggest printing out a copy of the GNU coding
>     standards, and NOT read it. Burn them, it's a great symbolic gesture."
>
>     -- 
>     Sebastian Huber, embedded brains GmbH
>
>     Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>     Phone   : +49 89 18 90 80 79-6 <tel:%2B49%2089%2018%2090%2080%2079-6>
>     Fax     : +49 89 18 90 80 79-9 <tel:%2B49%2089%2018%2090%2080%2079-9>
>     E-Mail  : sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>     PGP     : Public key available on request.
>
>     Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>     _______________________________________________
>     rtems-devel mailing list
>     rtems-devel at rtems.org <mailto:rtems-devel at rtems.org>
>     http://www.rtems.org/mailman/listinfo/rtems-devel
>
>

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35806
Support Available               (256) 722-9985

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20121204/7a694a31/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtems_style.tar.bz2
Type: application/x-bzip
Size: 7146 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20121204/7a694a31/attachment.bin>