Coding Style for RTEMS

[Jon Brinkmann]

Since NASA and some of it's contractors use RTEMs, we need to include their
standards @ http://lars-lab.jpl.nasa.gov/

Jon

On Tue, Dec 04, 2012 at 01:31:32PM -0500, 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.
>
> 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>
> >

> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel