<div dir="ltr"><div>First, I appreciate the effort and probably agree with the FreeBSD rule. Can you post a link?</div><div><br></div>I'm just not getting the nested rule out of the discussion so far. I can see a sequence like this being covered:<div><br></div><div>#if</div><div>#elif </div><div>#else</div><div>#endif</div><div><br></div><div>But not this:</div><div><br></div><div>#if </div><div> #if </div><div> #else</div><div> #endif</div><div>#endif</div><div><br></div><div>The latter is nested conditionals to me.</div><div><br></div><div>Also does any of this cover whether it is all in column 1 or in the second case, is an indentation allowed?</div><div><br></div><div>I have seen code where you are a few indentations levels in from the normal program logic and then an ifdef appears. If it is in column 1, the indentation flow is broken. If it follows the program indentation, does the condition code indent another level?</div><div><br></div><div>For most cases, putting it in column 1 is OK because that's where it obviously goes by program logic. But in others, the code may look nicer it it is indented. I picked this file randomly because I suspected it had multiple cases of conditionals in it. </div><div><br></div><div><a href="https://git.rtems.org/rtems/tree/cpukit/rtems/src/msgqcreate.c">https://git.rtems.org/rtems/tree/cpukit/rtems/src/msgqcreate.c</a> <br></div><div><br></div><div>It also has a decent example of having a section of code inside code that is already nested as being inside an if at line 114. </div><div><br></div><div>This file is pure "start in column 1". But would the code at 114 look better if the #if were at the program logic level?</div><div><br></div><div>Just asking. We have a lot of feature conditionals in code.</div><div><br></div><div>--joel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 13, 2020 at 9:33 AM Vaibhav Gupta <<a href="mailto:vaibhav.varodek@gmail.com">vaibhav.varodek@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 4 Apr 2020 at 01:44, Vaibhav Gupta <<a href="mailto:vaibhav.varodek@gmail.com" target="_blank">vaibhav.varodek@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Sat, Apr 4, 2020, 1:41 AM Vijay Kumar Banerjee <<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Sat, Apr 4, 2020 at 1:22 AM Vaibhav Gupta <<a href="mailto:vaibhav.varodek@gmail.com" target="_blank">vaibhav.varodek@gmail.com</a>> wrote:<br>
>>><br>
>>> CPP directives like:<br>
>>> 1) #if<br>
>>> 2) #ifdef<br>
>>> 3) #ifndef<br>
>>> 4) #elif<br>
>>> 5) #else<br>
>>> 6) #endif<br>
>>><br>
>>> do form code blocks. Since, they don't make use of brackets,<br>
>>> as a part of C language rule, their nested and repeated use<br>
>>> can make the code very hard to read. Can even result it<br>
>>> spaghetti code.<br>
>>><br>
>>> This can be understood by this patch:<br>
>>> <a href="https://lists.rtems.org/pipermail/devel/2020-April/058964.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-April/058964.html</a><br>
>>><br>
>>> The proposed idea is:<br>
>>> 1) Nested CPP directives should follow same indentation rules<br>
>>> as of nested conditional statements like 'if' and loops.<br>
>>><br>
>>> 2) To mark which closing CPP directive (#endif) pairs with which<br>
>>> opening CPP directive (#if or #ifdef or #ifndef), make use of comments.<br>
>>> ex:<br>
>>> #ifdef <some-macro> /* To test/verify/enable xyz */<br>
>>> .....<br>
>>> ....<br>
>>> #endif /* To test/verify/enable xyz */<br>
>>><br>
>> There's a rule like this in the FreeBSD<br>
><br>
> Yes, and when I ported APIs, last year, as a part of my<br>
> Project, the ported headers follow same rule.<br>
>><br>
>> and we follow it in RTEMS-libbsd.<br>
>> It is nicely explained in the FreeBSD style guide so I'm pasting an excerpt<br>
>> below:<br>
><br>
> Thanks!<br>
><br>
> --Vaibhav Gupta<br>
>><br>
>><br>
>> "<br>
>> The comment for #endif should match the expression used in the corre-<br>
>> sponding #if or #ifdef. The comment for #else and #elif should match the<br>
>> inverse of the expression(s) used in the preceding #if and/or #elif<br>
>> statements. In the comments, the subexpression "defined(FOO)" is abbre-<br>
>> viated as "FOO". For the purposes of comments, "#ifndef FOO" is treated<br>
>> as "#if !defined(FOO)".<br>
>><br>
>> #ifdef KTRACE<br>
>> #include <sys/ktrace.h><br>
>> #endif<br>
>><br>
>> #ifdef COMPAT_43<br>
>> /* A large region here, or other conditional code. */<br>
>> #else /* !COMPAT_43 */<br>
>> /* Or here. */<br>
>> #endif /* COMPAT_43 */<br>
>><br>
>> #ifndef COMPAT_43<br>
>> /* Yet another large region here, or other conditional code. */<br>
>> #else /* COMPAT_43 */<br>
>> /* Or here. */<br>
>> #endif /* !COMPAT_43 */<br>
>><br>
>> "<br>
>><br>
>> It would be nice to have a rule like this for RTEMS codes as well.<br>
>><br>
>><br>
>>> --Vaibhav Gupta<br>
<br>
Should it be included then?<br>
<br>
-- Vaibhav Gupta<br>
</blockquote></div>