Wrapping inside long statements is weird

[fejesjoco]

Wrapping inside long statements is weird

[JakeWharton]

So there's multiple statements here not just one which is why it gets weird when you try to use addStatement which was designed to emit a single statement.

Traditionally, constructs like if are meant to be created with beginControlFlow/nextControlFlow/endControlFlow. This automatically emits the correct indentation changes as well as handles the curly braces. It's nothing you can't do yourself, but it is meant to simplify things because KotlinPoet is not a compiler or lexer/parser and tries really hard to know nothing about what's going on in a statement (aside from where to break it when long).

[Egorand]

KotlinPoet prioritizes correctness, which we believe is more important in generated code than getting the formatting 100% right (though the library makes a decent effort at producing reasonably formatted code). If formatting is important, we usually recommend post-processing KotlinPoet's output with a formatter tool, such as ktlint.

[fejesjoco]

The example may be a bit wrong, since I work on proprietary code I have to make stuff up. My problems usually start when I have to call a statement, and within that I have to embed a lot of stuff, like other calls or lambdas. We can't embed that kind of stuff within an addStatement. And simply having too many parameters alone is a reason to avoid addStatement because of its wrapping behavior. But I agree that I prefer to use addStatement/beginControlFlow wherever possible.

At our company we have a massive amount of builds, and we have many code generators in the build pipeline (Bazel genrule), and we were asked to not format code as part of the builds because the total resource usage and effect on build time can be big if we add it all up. So we put some effort (not too much) into making the generated code look reasonable enough by default.

I think in this case using constructs like ⇥%L⇤ really makes a difference in the output. So I mainly wanted to suggest mentioning it in the official documentation. Because I'm not even sure if it's part of the public API. On top of that it would be great if addStatement wrapped at commas instead of wrapping at the column limit. Other than these two suggestions I accept that this is pretty open ended and there are no big benefits to be had here.

[Egorand]

I think in this case using constructs like ⇥%L⇤ really makes a difference in the output. So I mainly wanted to suggest mentioning it in the official documentation. Because I'm not even sure if it's part of the public API.

It is part of the public API, see docs for CodeBlock!

On top of that it would be great if addStatement wrapped at commas instead of wrapping at the column limit.

I don't think it'll be easy. We don't want to simply always wrap after a comma, don't think it'll be correct in many cases. Indentation is another concern which is not easy to get right. All in all, given that there are tools specializing in formatting Kotlin code, I don't think it's worth investing time into KotlinPoet's built in formatting rules (except for fixing obvious bugs and low-effort high-impact improvements). Completely understand your company's limitations though, it's a tradeoff.