rtems/src/scheduler* code convention issue

[Sebastian Huber]

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.

> Still no attempt at a community discussion.

This statement is not fair.

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