Often I'm in a situation where I want to wrap a co...
# ktlint
d
Often I'm in a situation where I want to wrap a code like this
Copy code
fun someFun(): Int {
   // ...
}
with some context-adding function. For instance
binding
from kotlin-result:
Copy code
fun someFun(): Int = binding {
   // ...
}
Unfortunately, this violates two rules: standard:function-signature and standard:multiline-expression-wrapping. I would like to avoid the reformat since it increases the indentation of the whole function body, thereby unnecessarily crippling git history. Since both these rules might be useful in different contexts I hesitate to simply switch them both off. Would it be possible to relax (possibly optionally - based on a setting) these rules in this situation? I.e. allow the function block to start on the same line as the function header.
p
Technically it will be possible. Functionally I am not convinced this is a good idea. If this would be allowed, than another developer will likely have an exception for another use case. In the end, it will result is way less clarity because there are too many exceptions.
d
Isn't the function-signature check duplicate with the one from multiline-expression-wrapping? Or is there any realistic scenario where there is "A multiline expression should start on a new line (standard:function-signature)" but not "Newline expected before expression body (standard:multiline-expression-wrapping)"?
e
IMO all assignments / expression bodies should be forced to start on same line as the preceeding statement so that the end of the block aligns (indentation-wise) with where it started..
👍 1
d
@Emil Kantis I don't fully agree because when the first statement is really long then it's quite confusing to me that majority of the statements in the block are visually to the left of the opening block/function name:
Copy code
val someReallyLongEnterpriseGradeValName = someReallyLongEnterpriseGradeFunName(par1, par2) {
    doSomething1()
    // ...
}
That looks quite strange to me and I would rather force this to
Copy code
val someReallyLongEnterpriseGradeValName =
  someReallyLongEnterpriseGradeFunName(par1, par2) {
    doSomething1()
    // ...
  }
The situation is different, however, for function bodies because a natural (and also ktlint) way to write a function is
Copy code
fun someFun(): Int {
   // ...
}
and not
Copy code
fun someFun(): Int
{
   // ...
}
So having to change the layout just because I formally convert from block to expression body is IMO wrong.
p
Isn't the function-signature check duplicate with the one from multiline-expression-wrapping?
Yes, there is some overlap. It is there for backwards compatibility with users who have disabled the
function-signature
.
d
Ok, would it make sense to you if only the function-signature rule cared about this? Because expression body is really a different case than a normal statement.
p
You might be interested in issue https://github.com/pinterest/ktlint/issues/2650.
d
Do I understand it correctly that you basically made the rule behave like I proposed in my last comment? 👍
p
I guess so. But looking at the date at which I created the issue, I already noted the issue myself before you reported it 😄 The funny think was that when I was picking up the issue, I was franticly searching for another issue that was adressing the same problem. Only later when I revisited this thread, I realized it was this thread I was searching for.
171 Views