Ktlint: Why new OperatorWrapping rule?

[Tolriq]

Can someone point the source for that decision?

Currently default for Java with checkstyle and many is to break before those.
http://checkstyle.sourceforge.net/apidocs/com/puppycrawl/tools/checkstyle/checks/whitespace/OperatorWrapCheck.html

Kotlin guide https://android.github.io/kotlin-guides/style.html#where-to-break says:
"When a line is broken at a non-assignment operator the break comes before the symbol."

So it seems consensus was more to have the break before the operator and as such && || at the start of the new line. It allows way better reading.

If there's no way to return to previous way is there a way to manage that via editorconfig or something?

[SUPERCILEX]

This technically comes from the Kotlin style guide, but I disagree with them, that if statement looks gross IMO. There should be a way to go back to the old behavior.

[shyiko]

"When a line is broken at a non-assignment operator the break comes before the symbol." can lead (in case of +/-) to confusing situations like:

var v = 1
    - 2
// v == 1 not -1

(more on this at https://github.com/android/kotlin-guides/issues/51).

&& / || at the EOL appears to be the default both in Kotlin Style Guide as @SUPERCILEX pointed out (+ in https://github.com/yole/kotlin-style-guide/issues/9#issue-157734134) and Google own code bases, e.g. https://github.com/android/android-studio-poet.

If decision is made (in https://github.com/android/kotlin-guides/issues/51) to wrap before && / || - ktlint will be updated to follow that rule. Until then, Kotlin Style Guide version is enforced for consistency reasons (personally I don't care which one is selected as long as there is only one).

[SUPERCILEX]

Alrighty, sounds fair.

[Tolriq]

@shyiko well thing is that for me consistency with the rest of the code base is more important :(
My apps are slowly migrating to Kotlin, consistency helps a lot to avoid human mistakes like missing parenthesis or operator orders so is mandatory at least during that phase even if keeping multiple years of habit would be nice.
If there's no way to have a choice on that I guess I'll be stuck at 0.15.1 :(

[kolboch]

Can this rule be disabled?

[Tapchicoma]

@kolboch yes, using disabled-rules: https://github.com/pinterest/ktlint#custom-editorconfig-properties

[kolboch]

@Tapchicoma , Thanks, actually found that later but thought it's still should be helpful as this discussion is something I found when investigating my issue. Right now I think I will make the same rule but with an exception to && and || operators. Do you think it is worth of pull request or that it is rather project-specific and should stay there to not mess up with guidelines?

[Tapchicoma]

Official styleguide is the target for this project rules, so in your case it should be project-specific custom rule.