Re: indentation uncertainty

[Rical Jasan]

On 02/06/2018 08:26 PM, Alexandre Oliva wrote:
> Hi, there,
> 
> Some uncertainly has come up during GCC patch review.

A reference to the debate would be nice.

>  I'd appreciate
> some clarification on the indentation rules in the GNU coding
> standards.  The current document states:
> 
>   Insert extra parentheses so that Emacs will indent the code properly.

To provide context from the "Formatting Your Source Code" section this
example is taken from [0]:

  "The rest of this section gives our recommendations...

  We don’t think of these recommendations as requirements, because it
  causes no problems for users if two different programs have different
  formatting styles.

  But whatever style you use, please use it consistently, since a
  mixture of styles within one program tends to look ugly. If you are
  contributing changes to an existing program, please follow the style
  of that program."

>   For example, the following indentation looks nice if you do it by
>   hand,
> 
>     v = rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
>         + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000;
> 
>   but Emacs would alter it.  Adding a set of parentheses produces
>   something that looks equally nice, and which Emacs will preserve:
> 
>     v = (rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
>          + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000);
> 
> It's not clear whether the first code snippet is incorrectly indented,
> or whether the only problem with it is that mechanical reindent will
> then make it improper.

Given the context of /recommended/ formatting, I would say the first
code snippet is correctly indented.

>  Mechanical reindent would turn it into:
> 
>     v = rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
>       + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000;
> 
> which is improper, presumably because '=' and '+' are at the same
> indentation level, in spite of being operators with different
> precedence, contradicting the earlier rule:
> 
>   Try to avoid having two operators of different precedence at the same
>   level of indentation.

I don't read the document as stating the non-parenthesized mechanical
indentation is "improper" as in "wrong" (actually, the way the
expression lines up is kind of nice, IMO), but it does _recommend_
keeping operators of different precedence at different levels.

How does the GCC codebase typically handle such formatting?  If there is
a mixture, is there a clear majority?  If not, then I would say take
your pick; otherwise the example has already been set.

Maybe consider a refactoring patch that settles the issue once and for
all.  ;)

> Now, what if, instead of as assignment, we had a return statement,
> without an '=' operator of higher precedence?

Perhaps return could be considered an operator (of higher precedence) in
this case?

> Would any of the following 4 forms be deemed improper in GNU code?

In my opinion/interpretation:

>     return rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
>            + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000;

No.

>     return (rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
>             + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000);

No.

>     return rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
>       + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000;

No.  Even if you were concerned with operator precedence, no two
operators of different precedence are indented at the same level (I
would consider the "operators" to be "return" and "+"), so you're still
indented according to the recommendation in that regard, but there may
be an issue with the fact the "+" is so far left of the beginning of the
expression.  I would defer to any project-based precedent here.

>     return
>       (rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
>        + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000);

No.  I could see this being particularly useful if something in the
expression caused this to be an overly-long line.

> If any of them are, the addition, to the standard document, of the
> snippet and rationale would be appreciated.

Again, some references to the debate would be nice, but I'm not sure
clarification is absolutely necessary.

Rical

[0] https://www.gnu.org/prep/standards/standards.html#Formatting