Skip to content
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

Conflict with Android Studio: Unexpected indentation (x) (should be y) #918

Closed
nokite opened this issue Sep 18, 2020 · 4 comments · Fixed by #1022
Closed

Conflict with Android Studio: Unexpected indentation (x) (should be y) #918

nokite opened this issue Sep 18, 2020 · 4 comments · Fixed by #1022

Comments

@nokite
Copy link

nokite commented Sep 18, 2020

I've seen similar issues but the consensus seems to be this works now. But in my experience, it doesn't.

Expected Behavior

Formatting a class using the built-in formatter of Android Studio should produce ktlint-compatible code (as long as the IDE uses the official Kotlin style)

Observed Behavior

Multiple violations reported by ktlint, even after reformatting the whole project from Android Studio.
It seems that ktlint and the Kotlin guys have different ideas about indentation in some special cases (see example).
P.S. I would not be surprised if ktlint sees it correctly, but there's a bug in Android Studio. However, ktlint seems inconsistent (compare the two examples).

Violation for ktlint:

    override fun actionProcessor():
        ObservableTransformer<in SomeVeryVeryLongNameOverHereAction, out SomeVeryVeryLongNameOverHereResult> =
        ObservableTransformer { actions ->
            // ...
        }

In the code above ktlint reports Some.kt:103:1: Unexpected indentation (8) (should be 12). (also reports indentation problems for the following lines, since they're from the same block)
Line 103 is the one with ObservableTransformer { actions ->.

In the snippet above there is a new line after actionProcessor(): in order to break the line that'd be too long otherwise. If I break it in a different way though, the problem disappears (even though the indentation is the same):
Works:

    override fun actionProcessor(): ObservableTransformer<in SomeVeryVeryLongNameOverHereAction,
        out SomeVeryVeryLongNameOverHereResult> =
        ObservableTransformer { actions ->
            // ...
        }

Steps to Reproduce

Customize maximum line length to 120 (probably not relevant)
Use the code I've provided.
Format with Android Studio
Run ktlint and see errors

Your Environment

  • Version of ktlint used: 0.39.0 (updated from 0.36.0)
  • Name and version (or code for custom task) of integration used: command line, custom Gradle task
  • Operating System and version: OS X 10.15.6
@Tapchicoma
Copy link
Collaborator

@romtsn worth to recheck this when you will address main issue

@chao2zhang
Copy link
Contributor

I have a similar issue, but would like to confirm that this issue is actually equivalent to this:

Expected Behavior

fun generateGooooooooooooooooogle():
    Gooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle {
    return Gooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle()
}

Because the return type cannot fit in with the function name, I have to move the return type into the next line.
I am using the "Kotlin Coding Convention" in the code style and applied the recommended IDE settings from ktlint readme as well. Reformatting in Android Studio does not change the code at all.

Observed Behavior

In ktlint:0.37.0, there are new violations detected:
/Users/cazhang/TestKtLint/app/src/main/java/com/chaozhang/testktlint/Main.kt:7:1: Unexpected indentation (4) (should be 8)
/Users/cazhang/TestKtLint/app/src/main/java/com/chaozhang/testktlint/Main.kt:8:1: Unexpected indentation (0) (should be 4)

To make it pass, the code needs to be formatted into the following:

fun generateGooooooooooooooooogle():
    Gooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle {
        return Gooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle()
    }

Reformatting in Android Studio changes the code back to the expected behavior.

Your Environment

  • Version of ktlint used: 0.37.0 (Verified that the violations are new in 0.37.0)
  • Name and version (or code for custom task) of integration used: command line, custom Gradle task
  • Operating System and version: OS X 10.15.6

@XabierGoros
Copy link

I'm experiencing the same behavior when using ktlint, here are some cases:

Case 1:

if (records.containsKey(AdvRecord.TYPE_UUID128) && Arrays.equals(
        Config.MYOWN_GATT_SERVICE_RAW,  // <-- Unexpected indentation (expected 12, actual 16)
        AdvRecord.getServiceUUID128(records[AdvRecord.TYPE_UUID128]!!) // <-- Same as above
    ) // <-- Unexpected indentation (expected 8, actual 12)
) {
    ...
}

Case 2

if (TextUtils.isEmpty(oldContext.aaaaaaaaaaaaaaaaaaa) || !Bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.ccccccccccccccc(
        oldContext.aaaaaaaaaaaaaaaaaaa // <-- Unexpected indentation (expected 24, actual 28)
    ) // <-- Unexpected indentation (expected 20, actual 24)
) {
    ...
}

Case 3

if (!customBleService.enableCharacteristicNotification(
        myCharacteristic, // <-- Unexpected indentation (expected 24, actual 28)
        true // <-- Unexpected indentation (expected 24, actual 28)
    ) // <-- Unexpected indentation (expected 20, actual 24)
) {
    ...
}

However, if I change manually to the expected result, ktlintCheck task complains about the same lines to be changed into the previous code indentation again. I don't understand anything. What I'm trying to achieve is Android Studio IDE code reformat fits with ktlint criteria, and somehow they're unsynced now.

I have even tried to run ktlint --android applyToIDEAProject from command line to apply project specific code style, but the problem persist. Any idea how to solve this guys?

My environment

  • Version of ktlint-gradle used: 9.4.1
  • AS 4.0.1 with AGP 4.0.1
  • Operating System and version: MacOS 10.15.7

@nokite
Copy link
Author

nokite commented Oct 26, 2020

@XabierGoros my temporary workaround is one of these:

  • avoid code bocks that result in this conflict (extract checks into variables, change where you break off the line etc)
  • use // @formatter:off and // @formatter:on around the problematic code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants