rtems/src/scheduler* code convention issue

[Sebastian Huber]

On 2014-05-20 20:43, Sebastian Huber wrote:
> On 05/20/2014 05:30 PM, Joel Sherrill wrote:
>> On 5/20/2014 10:17 AM, Sebastian Huber wrote:
>>> >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".
>> The BSPs and drivers are not good examples of anything and we have all
>> long stated that. The APIs and score portion of cpukit was reasonably
>> consistent.
>>
>> Your response is simply that "I couldn't find the answer so I did what I
>> wanted"
>
> You said I violate a rule and I said that there is no such rule in the coding
> style
>
> http://www.rtems.org/wiki/index.php/Coding_Conventions
>
> and that there are good reasons to not follow such a rule.  It was simply not
> clear to me that were was a "avoidance of deep nesting by using early returns"
> rule.  If I look now at the code, then there are indeed a lot of examples for
> this rule.
>
> All I ask is that rules that should be enforced should be part of the coding
> style.  This lack of a proper coding style makes it hard for newcomers (e.g.
> GSoC students or new colleagues) to get started with RTEMS development.  I
> leads also to discussions like this.

We still have no new rule for "avoidance of deep nesting by using early 
returns" in the wiki page.  So we are still in the situation that everyone 
interested in code contributions must deduce this rule himself from the "almost 
200 API calls which take object ID and have the _Object_Get() switch".

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