<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 12/04/2012 12:31 PM, Gedare Bloom wrote:
<blockquote
cite="mid:CAC82fA23S90BZU4eWKz3jbM_awoHPbu6vVVo5PYdmFW--EdDFg@mail.gmail.com"
type="cite"><br>
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.
<div class="gmail_extra">
<br>
</div>
</blockquote>
How incomplete is up for debate. :)<br>
<br>
I have attached what I have and there is a Wiki page which<br>
also captures some of the rules.<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="http://www.rtems.org/wiki/index.php/Coding_Conventions">http://www.rtems.org/wiki/index.php/Coding_Conventions</a><br>
<br>
My cynical view is that no one but me has ever written a line <br>
on Coding Style, there was no auto-reformatting, no way to<br>
reformat non-conformant code, and thus it was easy for <br>
those who didn't like the style to ignore it.<br>
<br>
Not picking on Sebastian.. but his editor randomly reformatted<br>
the license text into two lines. I only recently managed to kill<br>
all these.<br>
<br>
So my view is that we need to follow the RTEMS style which<br>
was used in the core, tighten it, define it and find tools<br>
which help.<br>
<br>
Third party code should NOT NOT NOT be reformatted.<br>
<br>
I can put the attached document in git if we want to<br>
commit to actually writing it.<br>
<br>
I am also happy to discuss coding standards from NASA, ESA,<br>
JPL, MISRA, etc. but they better make sense for RTEMS and<br>
be enforceable by free tools.<br>
<blockquote
cite="mid:CAC82fA23S90BZU4eWKz3jbM_awoHPbu6vVVo5PYdmFW--EdDFg@mail.gmail.com"
type="cite">
<div class="gmail_extra">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.<br>
<br>
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.<br>
<br>
Rules that conflict explicitly between BSD and RTEMS style
include:<br>
* use of tabs<br>
* no space after ( and before ) in if/for/etc statements<br>
* variable declaration name alignment<br>
<br>
Points where RTEMS style implicitly conflicts with BSD include:<br>
* avoid typedefs<br>
* \ aligned to the far right<br>
* function type on line before function name<br>
* variable declarations sorted by size and alphabet<br>
<br>
It might also be nice to define rules about assembly, both
inline and in .S files.<br>
<br>
-Gedare<br>
<br>
<br>
<div class="gmail_quote">On Tue, Dec 4, 2012 at 12:50 PM,
Sebastian Huber <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sebastian.huber@embedded-brains.de"
target="_blank">sebastian.huber@embedded-brains.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
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:<br>
<br>
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.).<br>
<br>
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.<br>
<br>
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.<br>
<br>
<a moz-do-not-send="true"
href="http://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html"
target="_blank">http://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html</a><br>
<br>
Another one is the Linux coding style.<br>
<br>
<a moz-do-not-send="true"
href="http://www.kernel.org/doc/Documentation/CodingStyle"
target="_blank">http://www.kernel.org/doc/Documentation/CodingStyle</a><br>
<br>
For the GNU style let me quote the document above:<br>
<br>
"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."<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany<br>
Phone : <a moz-do-not-send="true"
href="tel:%2B49%2089%2018%2090%2080%2079-6"
value="+4989189080796" target="_blank">+49 89 18 90 80
79-6</a><br>
Fax : <a moz-do-not-send="true"
href="tel:%2B49%2089%2018%2090%2080%2079-9"
value="+4989189080799" target="_blank">+49 89 18 90 80
79-9</a><br>
E-Mail : <a moz-do-not-send="true"
href="mailto:sebastian.huber@embedded-brains.de"
target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne
des EHUG.<br>
<br>
_______________________________________________<br>
rtems-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:rtems-devel@rtems.org" target="_blank">rtems-devel@rtems.org</a><br>
<a moz-do-not-send="true"
href="http://www.rtems.org/mailman/listinfo/rtems-devel"
target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Joel Sherrill, Ph.D. Director of Research& Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35806
Support Available (256) 722-9985</pre>
</body>
</html>