[llvm-dev] Change coding style for argument alignment?

Nicolai Hähnle via llvm-dev llvm-dev at lists.llvm.org
Mon Dec 21 22:00:50 PST 2020


On Sat, Dec 19, 2020 at 8:15 PM antlists via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 19/12/2020 18:35, Chris Lattner via llvm-dev wrote:
> > On Dec 3, 2020, at 1:00 PM, Nikita Popov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >> Hi,
> >> LLVM currently uses a coding style where arguments and parameters need
> to be aligned to the opening parenthesis "(".
> >>
> >>      someFunctionCall(Arg1, Arg2,
> >>                       Arg3, Arg4);
> >>
> >> This style guideline is unfortunate for a couple of reasons:
> >>
> >> 1. If a function is renamed, it is necessary to also reindent the
> arguments at all call-sites. For functions with many or complex arguments,
> this may require significant reflow.
> >>
> >> 2. It causes significant right-ward drift. Especially for declarations,
> it's somewhat common for code ending up like this...
> >>
> >>     Foo SomeClassName::someMethodName(Bar &Arg1,
> >>                                        Bar &Arg2,
> >>                                        Bar &Arg3,
> >>                                        Bar &Arg4) {
> >>
> >> ... because there is just enough space to fit each argument
> individually, but still a need to break each one out on a separate line.
> Closure arguments are another common case of very awkward formatting.
> >>
> >> 3. There are some arcane rules about when this is not the preferred
> style and you're supposed to indent arguments on the following line instead.
> >>
> >> Is there any chance that the style could be changed towards indenting
> (but not aligning) the following line instead?
> >>
> >>      someFunctionCall(
> >>          Arg1, Arg2, Arg3, Arg4);
> >>
> >> This is unaffected by renames, does not cause rightward drift and
> results in very predictable formatting.
> >>
> >> Based on past discussions, LLVM seems to be open to improving coding
> style for the better, so I thought I'd give this a shot, as this is a
> continuous source of friction for me.
> >
> > I support this change.  I think you’ve done a good job of laying out a
> principled reason that this approach is better, and I don’t see any
> significant advantages to the current approach.  We should obviously keep
> the arguments on the same line if they fit though.
> >
> There's a big argument against the current standard, which is that if
> you have several functions next to each other, they are all formatted
> differently. Very confusing on the eyes.
>
> My personal preference would be either (a) all arguments on one line if
> there's room (either with the function name, or the line below), or (b)
> one argument per line with an indent of either one or two from the start
> of the function name.
>

To add my €0.02, whatever the common form is there are times when it makes
more sense to escape from it. A common example is where a function has
arguments that come in pairs -- common in UI toolkits with x/y or w/h pairs
-- and the formatting should reflect that. It's less common in LLVM, though
I've seen it happen. Being slightly more relaxed with such things would be
great.

That said, the proposed change is clearly better even in this case, because
while

someFunctionCall(
    x1, y1,
    x2, y2);

is best, I'd say that

someFunctionCall(
    x1,
    y1,
    x2,
    y2);

is far better than the

someFunctionCall(
    x1, y2, x2,
    y2);

that the current style likes to generate.

Something analogous happens with &&- or ||- chains in conditionals.

Cheers,
Nicolai


>
> Cheers,
> Wol
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201222/051dc6c0/attachment.html>


More information about the llvm-dev mailing list