Coding Style for RTEMS

[Ralf Corsepius]

On 12/04/2012 06:50 PM, Sebastian Huber wrote:
> Hello,
>
> we need a formal coding style for RTEMS since otherwise it is very hard
> for newcomers to do things right.

Why are you saying, we _need_ a coding style?

I do not see any such _need_. I agree, having one for new contributions 
would be _nice to have_, but enforcing a coding style on old code and 
code with external origin would seem harmful, IMO.

Also, why would having a coding style, make "doing things right" easier 
for newcomers? I don't buy this argument. Any code a newcomer hasn't 
seen before, is "Greek".

What one considers better readable/understandable is largely a matter of 
experience and personal preference. It's pretty likely, other people 
will consider our "favorite style" to be "utter crap" and vice versa.

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

I think it's not a question of having "1 or 2 styles", it's a question 
of "what causes the least churn".

E.g. I mean, code with externals origins is best kept as close to its 
upstream as possible and not be reformated.

> 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.
Correct ... one origin.

> Other parts in RTEMS have no consistent coding style.
Correct, ... different origins.


>  I suggest to use
> a well established coding style for these and enforce it for new files.

I do not agree. You should take into account that many contributions in 
RTEMS originate from different origins and have forks in external source 
trees.

To this kind of cases, all that reformating would do, would be churn 
(e.g. as whitespace changes) and to break the formating these other 
parties are using for other, unknown reasons.

Example: Let me reformat all EMB contributed BSPs  to GNU style and 
you'll experience what I am referring to.

Ralf