On 9/11/20 5:50 pm, Sebastian Huber wrote:
> On 09/11/2020 01:52, Chris Johns wrote:
>
>> On 6/11/20 7:11 pm, Sebastian Huber wrote:
>>> Hello,
>>>
>>> for breaking long lines we have currently:
>>>
>>> "Should be replaced with
>>>
>>> .. code-block:: c
>>>
>>> for (
>>> initialization = statement;
>>> a + really + longish + statement + that + evaluates + to <
>>> a + boolean;
>>> another + statement++
>>> ) {
>>> z = a + really + longish + statement + that + needs +
>>> two + lines + gets + indented + four + more +
>>> spaces + on + the + second + and + subsequent +
>>> lines + and + broken + up + at + operators;
>>> }
>>>
>>> Note that indentations should add 2 nesting levels (4 space characters, not
>>> tabs)."
>>>
>>> Do we really need two indent levels for breaking long lines in block
>>> statements?
>>> I would just say that the continuation of a broken line is indented by one
>>> level. The example would look like this (please note the change in the for
>>> loop
>>> "a + boolean"):
>>>
>>> .. code-block:: c
>>>
>>> for (
>>> initialization = statement;
>>> a + really + longish + statement + that + evaluates + to <
>>> a + boolean;
>>> another + statement++
>>> ) {
>>> z = a + really + longish + statement + that + needs +
>>> two + lines + gets + indented + four + more +
>>> spaces + on + the + second + and + subsequent +
>>> lines + and + broken + up + at + operators;
>> I sometimes add parentheses to aid indenting:
>>
>> z = (a + really + longish + stat
>> ....
>> lines + and + broken + up + at + operators);
>>
>> Emacs automatically indents to the opening `(`. This is mentioned in the GNU
>> coding standard. We however have this statement in our standard ...
>>
>> Avoid excess parentheses. Learn the operator precedence. rules.
>
> Yes, and I think this is a good rule.
I am not sure it is a good rule and workable. Using it to handle indents is an
example of it breaking down. The ability to control an indent is a long held
tradition and editors like Emacs are designed to handle it yet it is not clear
if it is OK under this rule.
Is explicit grouping more robust in the face of changes? I find it a little
ironic extra braces are considered good practice because code can change but we
consider explicit grouping with parentheses is not?
The next rule is an exception for sizeof however return is not discussed. Then
there is `x = ((char)y) == 'a' ? 0 : 1` logic and finally type promotion. Making
sure the logic is right and then laying the need to deal with this rule on top
makes things harder. There are a bunch of difficult corner cases such as macros,
eg `#define SOMETHING(xxxx) ((xxx) + 1)`. How is "excess" defined here?
I get the purpose is about 'if' statements but the rule is fragile.
Anyway this is off topic.
> My question is if we really should indent by two levels for the continuation
> of
> long lines.
And my answer was it depends on what is being indented and why. The block
nesting level can also effect what works.
> variable = ...
>
> <SP><SP><SP><SP>foo bar continuation ...
>
> vs.
>
> variable = ...
>
> <SP><SP>foo bar continuation ...
I think most editors will assume this level of indenting rather than the double
indent level.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
