[cfe-commits] r171357 - in /cfe/trunk: lib/Format/Format.cpp unittests/Format/FormatTest.cpp

[Chandler Carruth]

On Wed, Jan 2, 2013 at 10:58 AM, Daniel Jasper <djasper at google.com> wrote:

> Well, this patch only consolidates the "int f() {}" and "int* f() {}"
> cases, so it is a step into the right direction. If we implement the line
> break you are suggesting, we should do so deliberately ;-).
>
> clang-format currently formats like (assuming "bar" does not fit on the
> first line):
>
> int foo(
>     int bar,
>     int baz);
>
> int *foo2(
>     int bar);
>
> I personally would prefer that over the other solution, but it is
> obviously a matter of taste (I didn't find anything in the style guide).
>

This got me thinking. Random thoughts follow, sorry if it's duplicating
thoughts already had and written up by someone elsewhere.

I suspect it is useful to first imagine the extreme case:

static inline
template <
    typename LongT1,
    typename LongT2>
LongNameSpace1
  ::LongNameSpace2
  ::LongReturnType
LongNameSpace1
  ::LongNameSpace2
  ::LongFunctionName(
    LongNameSpace1
      ::LongNameSpace2
      ::LongParamType1
        LongParamName1,
    LongNameSpace1
      ::LongNameSpace2
      ::LongParamType2
        LongParamName2) {
  // Some code...
}

Now imagine each 'Long' name having too many characters to remove any line
breaks in the above. I think this is the worst-case scenario[1], and at
this point we should exceed 80-columns because there is just no hope....

>From there, I see three interesting considerations:
1) On which side of a separator do we break a line? for '(' and ',' we
break after very consistently, but '::'? '&&'? There are mixed opinions
here. I don't hold any particularly strong opinions that aren't already
enshrined in convention (for '(', ',' and ';').

2) How much do we indent the next line? Starting from what position? This
is easier when we can line up vertically a list. When the items in that
list are too long to line up vertically, where do we start? I actually have
some strong opinions here. They mostly center around ensuring that when we
indent for two different purposes they get indented by a different amount
visually. For example:

SomeLongFunction(
    int SomeParam,
    int SomeOtherParam) {
  int MyLocalVariable;
  // ...
}

Is dramatically more readable to me than this:

SomeLongFunction(
  int SomeParam,
  int SomeOtherParam) {
  int MyLocalVariable;
  // ...
}


3) How do we weight the different places that we might break a line when we
don't require breaking on all of them. I think this is your question
Jordan. I'm not sure where the balance point should be between breaking
after the '(' versus before the function name, and I don't have terribly
strong preferences here with one exception: I think I'd be willing to trade
off almost any linebreak point *if* doing so allows us to move from a
generic indent to a lined up vertical column. That would I think address
your concern Jordan.

However, I think it would be good to get some of these extreme examples
into the tests early, and start making sure we have good answers for #1 and
#2 above, before we start really digging into #3. The reason is that
personally I will misjudge the tradeoffs between the various options in #3
when one of those options happens to be laid out more poorly due to
incomplete work on #1 and #2. When we can layout *all* of the line break
candidates "perfectly" (as best we can figure out), then we can make a more
informed decision on what the relative tradeoffs should be in #3.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130102/1b2d1496/attachment.html>