Coding Style for RTEMS

Gedare Bloom gedare at rtems.org
Tue Dec 4 18:54:52 UTC 2012


I had this thought as well. What conventions / standards to make users jobs
easier when integrating/reviewing/certifying rtems?
-gedare
On Dec 4, 2012 1:50 PM, "Jon Brinkmann" <brinkmann at nmsu.edu> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20121204/4525ac9d/attachment-0001.html>


More information about the devel mailing list