rtems/src/scheduler* code convention issue

[Sebastian Huber]

On 2014-05-20 16:58, Joel Sherrill wrote:
> On 5/13/2014 1:16 AM, Sebastian Huber wrote:
>> >On 2014-05-13 01:28, Joel Sherrill wrote:
>>> >>Hi
>>> >>
>>> >>Both schedulerident.c and schedulergetprocessorset.c do not follow
>>> >>RTEMS Coding Conventions on avoidance of deep nesting by using
>>> >>early returns.
>> >I don't find such a rule here:
>> >
>> >http://www.rtems.org/wiki/index.php/Coding_Conventions
>> >
>>> >>The nesting on schedulergetprocessorset.c is pretty
>>> >>ugly and could have been avoided easily.
>>> >>
>> >I prefer a single exit point.  This is also advised by MISRA Rule 15.5.  It is
>> >required by ISO 61508 and ISO 26262.  It is also "will" rule (AV Rule 113) of
>> >the "JOINT STRIKE FIGHTER AIR VEHICLE C++ CODING STANDARDS FOR THE SYSTEM
>> >DEVELOPMENT AND DEMONSTRATION PROGRAM".
>> >
>> >http://www.stroustrup.com/JSF-AV-rules.pdf
>> >
>> >So if you ask me, then we should also add this to the our coding conventions.
>> >
> I'll be honest. I don't really care what the JSF rules or MISRA rules
> say. At this point in the "discussion", what they say is completely
> irrelevant to this situation. Whether I like this rule or not, the fact
> remains that
>
> (1) There was no community discussion.

I made several attempts to improve the coding style on the wiki.  This is an 
ongoing process.

> (2) There is no way to enforce it (or any other rule)
> (3) It is an arbitrary change and leads to inconsistent
> code in the code base.
>
> (1) and (3) really bother me.  (2) we have lived with a long time.
> I don't like it but we haven't figured out how to solve that.
>
> The only community discussion was me asking why you didn't
> follow existing practice.

There are so many coding styles in the RTEMS code base that it is hard to guess 
the "existing practice".

>
> With no community discussion, this implies that one person can
> make decisions for the community. This was a serious decision and
> the thread consisted of 3 emails with the first being me asking
> why you didn't follow existing practice. There was no discussion
> of changing style, how existing code would be impacted, inconsistency
> addressed, etc..
>
> That doesn't sound like a healthy discussion to change 25 years
> of coding practice -- written style guide or not, you can look at the
> code and see it. There are almost 200 API calls which take object ID
> and have the _Object_Get() switch. Those are pretty damned
> obvious ignoring any other code.

No, looking at a random set of files to guess the "existing practice" is not an 
option.  My point is that if you want me to follow a certain rule, then we have 
to add this rule to the coding style.  I have no problem with a rule like 
"avoidance of deep nesting by using early returns".  I just wanted to highlight 
that there are some standards that use different rules.

>
> Inconsistent coding is an indication that we are not a community.
> This detracts from the code base.  Were you volunteering to
> reformat the code to follow the new rule?

I would not reformat unless this can be done by a tool.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
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.