Updated Style and Coding Conventions

[Joel Sherrill]

On 6/2/2014 2:07 AM, Sebastian Huber wrote:
> Hello Gedare,
>
> thanks for the summary.  I have some comments.
>
> "Exception: Spaces are optional around binary bit-wise operators."
>
> What is the background for this exception?  So "a&b" is ok, but not "a&&b"?  I 
> would remove this exception.  I think "a & b" is much easier to read.
I am surprised at this one myself. I thought both cases should have
spaces around them.
> "Put a single space before and no space after unary pointer operators (* and &)."
>
> What about "!a" vs. "! a"?  We have both variants currently.
I am more fond of !a personally. Something about the space there is
unnatural.
> "Use NULL for the null pointer."
>
> What is with tests for the null pointer, e.g. "!ptr" vs "ptr != NULL".  I 
> strongly favor the "ptr != NULL" test.  This is also in line with MISRA C and 
> other standards in that area (only expressions with a boolean result value are 
> allowed in if statements).
This will be hard to address in existing code but I do like the explicit
NULL.
> We should add a rule for unused function parameters:
>
> "Use '(void) unused;' to mark unused parameters."
>
> This works without special attributes and uses vertical space, so long function 
> declarations are avoided.
I am OK with this. I don't know how long this trick has worked which is
probably why
it wasn't in the original rules. Of course, gcc didn't generate many
warnings back then
for things like this so we would never have noticed. The usual case is
task bodies which
ignore their argument. In that case naming it unused was sensible. In
other cases
(which are much more common now), you have a function pointer and are just
not using all the arguments. You should stick to the defined names for
the parameters
and use this.
> On 2014-05-29 23:03, Gedare Bloom wrote:
>> Hi,
>>
>> Please have a look http://www.rtems.org/wiki/index.php/Coding_Conventions
>>
>> I included some of the recent discussion points we've had, and some
>> other points that come up often during code review.
>>
>> Gedare
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985