Install ktlint plugin

[bmarty]

Draft for now.

Iteration call to ./gradlew ktlintCheck does not give the same result :/

[EDIT]

It's OK now, ktlint plugin is working as expected.

The following rule are now enabled (were disabled before):

• colon-spacing
• chain-wrapping
• import-ordering

Fixes #2820

[erikhuizinga]

Try running ./gradlew ktlintCheck --continue. If that leads to identical results, it might be an indication of ktlint running checks randomly. That might explain the non-determinism. I think that the ktlint Gradle tasks fail on the first found problem, while there might be more to find after the first.

[bmarty]

There is still a problem, Android Studio does not always order imports correctly :/

[github-actions]

Unit Test Results

  42 files  ±0    42 suites  ±0   54s ⏱️ ±0s
  83 tests ±0    83 ✔️ ±0  0 💤 ±0  0 ❌ ±0 
220 runs  ±0  220 ✔️ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 587c634. ± Comparison against base commit 587c634.

♻️ This comment has been updated with latest results.

[erikhuizinga]

I think that the import ordering issues have been discussed extensively on the ktlint repo. Note that various settings can affect the import ordering, e.g. Android Studio settings for the Kotlin language and for the project. I can't check right now, but there might be a ktlint setting that tells ktlint that the project uses IntelliJ / AS. Ktlint then knows that the import ordering should use different rules.

[erikhuizinga]

See also https://github.com/pinterest/ktlint#custom-ktlint-specific-editorconfig-properties.

[bmarty]

Thanks @erikhuizinga . I've force push the branch with latest improvement.
First commit 03bdcee is the important change, next commits are done by enabling disabled rules one by one and run ./gradlew ktlintFormat

[bmarty]

So the ktlint plugin is now working as expected.

The following rule are now enabled (were disabled before):

• colon-spacing
• chain-wrapping
• import-ordering

[BillCarsonFr]

I'd prefer to keep && and || formating as it is currently

[ouchadam]

thanks for this 💯

some of the line breaks for closing fun parameters/constructors etc are a little strange with

class Foo(val prop: Long) : 
  RealmObject() {
}

but they should be easy enough to fix later on with a find replace/regex

would have expected to see either...

class Foo(val prop: Long) : RealmObject() {
  ...
}

or

class Foo (
    val prop: Long
) : RealmObject() {
  ...
}

[bmarty]

I'd prefer to keep && and || formating as it is currently

Yes, me too, but see pinterest/ktlint#163 (comment)

[bmarty]

@ouchadam yes, I agree with you,some constructors are not nicely formatted. Your latter proposal is good to me. As you said we can manually change that later, I wanted to keep manual commits as minimal as possible in this PR, since it's not possible to review it...

[bmarty]

Fixes #2820

[erikhuizinga]

Just under 600 files changed... 😅

Agreed: if ktlint accepts the current formatting, then this PR is acceptable. Apply the boy scout rule later when you work on lines of code with strange formatting.

For class definitions with constructor arguments I prefer oneliners, but if too long I prefer to put arguments in one column, possibly even with a trailing comma after the last argument. The same goes for long lists of super types: first one comes after ): and the rest on their own lines.

Is that how the current PR configure ktlint, so what I just said is acceptable formatting?

[bmarty]

another advantage is that dependabot is now able to upgrade the tool: #4138 :)