Coding Style for RTEMS

[Sebastian Huber]

On 04/12/12 14:00, Joel Sherrill wrote:
> 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.

The score style is pretty easy to capture from the source. The score is 
not the problem.  The big problem is the code outside the score, e.g. 
shell, file systems, bdbuf, BSPs.

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

I instructed the editor to do this and it was an error out of accident.

>
> 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.

Yes.

>
> Third party code should NOT NOT NOT be reformatted.

Yes, absolutely.

>
> 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.

Ok, a coding standard is quite complex and taking all this into account 
can be a matter of years.  Some MISRA rules are quite questionable for 
example.  Standards may contradict each other.  For a start I am happy 
with a coding style (source code layout) that can be enforced with a 
tool.  Consider the following problem.  You are new to RTEMS and want to 
contribute code.  Lets say in the file system.  Some parts of the file 
system code are a nightmare with respect to coding style.  You send a 
patch to the mailing list and get comments about the style.  How should 
you know what to do?

I have not problems with the score style personally.  My only concern is 
that it makes it harder for newcomers since a lot more people already 
know the BSD, Linux or GNU style.

-- 
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
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.