Closing parentheses placement for method calls does not match Kotlin style guide about ktfmt

[andrewparmet]

My vote is a new line, wasting the vertical space. IMO the consistency is what I value.

[cgrushko]

@JavierSegoviaCordoba I'm hesitant to introduce special formatting cases such as builder patterns. First, because I'm concerned it'll complicate the code and make it less maintainable, and second because it might be difficult to correctly identify the pattern.

[cushon]

Another related question is what to do about chained method calls if there's a line break before ).

Having a line break and continuation indent after . looks weird and takes up more vertical space. It might be better to have something like the following, but it would require some rectangle rule special-casing:

foo(
    bar,
).baz(
    bork,
)

[cgrushko]

This is the existing formatting:

func f() {
  computeBreaks(
      output.commentsHelper, maxWidth, State(0))
…

Which one do we prefer?

First option wastes vertical space:

…
  computeBreaks(
      output.commentsHelper,
      maxWidth,
      State(0)
  )
…

Second option looks weird:

…
  computeBreaks(
      output.commentsHelper, maxWidth, State(0)
  )
…

I don't like either of the options, but the first one seems more sane.

EDIT: For method parameters, we use the latter.

@cushon, @strulovich, what says you?

[strulovich]

In any case, for a trailing comma we will do:

func1(
    arg1,
    arg2,
)

But I'd prefer keeping it for now as:

func1(
    arg1,
    arg2)

I'm against wasting vertical space. So if all args fit in one line I would keep them there.

Is any of these a deal breaker for anyone?

[cgrushko]

Do you mean we output different formatting based on whether a trailing comma exists?

[strulovich]

As long as we don't adjust the actual tokens (which for now we are not) I think that would be ok.

[strulovich]

Doing round on some old issues today. I prefer same line if if there's no trailing comma, and next line if there is one. We do not add or remove commas for now.

@cushon, how does that sound to you?

[bethcutler]

At Google, we are using the first option (all parameters on separate lines, closing parens on its own line). This is also the style that ktlint enforces (all parameters must be on separate lines, unless they can all fit on the same line as the function name).

The closing parens being on its own line is also key to having no continuation indents, as recommended by both Intellij and Android style guides. (See also discussion at #14 )

[JavierSegoviaCordoba]

I like the approach of trailing lambdas to force multiline params even if it fits in one line.

But I would like to force in a builder pattern to use multiline even if it fits in one line because of readability.

The only approach now is this?

fol.Builder().apply {
    bar()
    baz()
}