-
Notifications
You must be signed in to change notification settings - Fork 503
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Indentation change since 0.38.1 #1217
Comments
can sb pls look at this? |
Problem is not reproducible in ktlint 0.43.x |
It still hapens for me once I use the |
I double checked it once more on my site, but it works fine. Please provide me details about following:
|
trying this:
private fun transactionOf() = PurchaseTransaction().also {
it.timestamp = timestamp
it.timestampDesk = timestamp
it.sale = testSale
it.count = count
it.amountCents = amountCents
it.reserved = reserved
it.dealSplit = mutableListOf(
PurchaseTransactionDeal().also {
it.sale = testSale
it.deal = testDeal
it.count = count
it.amountCents = amountCents
}
)
}
|
Another failing example is:
works correctly without |
@knyttl Your examples do not seem to be related to the original problem of @dalewking. Your problem is already addressed in #1284. |
@dalewking This problem is indeed not solved. Due to the partial code sample, I misinterpreted it before. A complete code sample, reproducing the problem is:
|
I did some further investigation. The current behavior has been built-int on purpose as a result of #964. I have verified in IntelliJ Ultimate and the default formatting for the example above is:
Personally, I would prefer to change the formatting as has been requested. However, it conflicts with the (default) IntelliJ / Android Studio formatting. One of our code policies, is that code that is formatted by ktlint should be accepted by the default IntelliJ formatting without any conflicts. |
The fact that IntelliJ / Android Studio format the code that way shouldn't matter, since it is incorrect according to Jetbrain's own style guide. Unfortunately they don't have a rule specifically about named parameters, but we can infer from several very similar rules:
Considering the purpose of the style guide is for consistency to begin with, this formatting quirk in IntelliJ is a bug, not a feature to emulate. |
While I agree with you that ideally IntelliJ should fix its formatter, I don't think it is realistic to ignore IntelliJ's integrated formatter. It would be bad for developer's user experience to turn off integrated IDE formatter and only rely on external ktlint formatter. |
Could we maybe have some flag for this, which could be disabled? I personally prefer to have a nice code than just follow a weird IDE behaviour. |
This issue first needs to be resolved in the IntelliJ formatter. Please file an issue at their tracker first.
Ktlint should not offer such a flag for a minor issue like this. |
This seems backwards to what ktlint should be doing. Adhering to random and unexplained behavior in IntelliJ to the letter instead of examining the situation and choosing the better option ('better' being what everyone here is agreeing with) is not an admirable quality for a formatter like this. I use ktlint to remove the ambiguity of IDE formatting, not the other way around. |
I created an issue for IntelliJ which relates to this: https://youtrack.jetbrains.com/issue/IDEA-291053 |
* Allow value arguments with a multiline expression to be indented on a separate line Closes #1217 * Add rule `multiline-expression-wrapping` which forces multiline expressions to start on a separate line * Fix lint violations caused by `multiline-expression-wrapping`
Expected Behavior
Upgrading from 0.38.1 to latest I see a change in indentation with parameter names in a call.
For example this was allowed in 0.38.1:
Observed Behavior
With 0.41.1 it now demands that it be indented like this:
Which is not very readable.
I can make it go away by moving someValue to same line as parameter name:
But sometimes there is a longer expression than this example and it is more readable to move it to its own line.
The text was updated successfully, but these errors were encountered: