Coding Style for RTEMS

[Gedare Bloom]

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.

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> 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<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
> Fax     : +49 89 18 90 80 79-9
> E-Mail  : sebastian.huber at embedded-**brains.de<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
> http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20121204/cb93f190/attachment-0001.html>