Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add new codestyle KtLint Official #1699

Closed
paul-dingemans opened this issue Nov 6, 2022 · 2 comments · Fixed by #1767
Closed

Add new codestyle KtLint Official #1699

paul-dingemans opened this issue Nov 6, 2022 · 2 comments · Fixed by #1767

Comments

@paul-dingemans
Copy link
Collaborator

paul-dingemans commented Nov 6, 2022

Currently KtLint supports the Kotlin Coding Conventions and Android's Kotlin styleguide. Both codestyles try to prevent conflicts with the IntelliJ IDEA Default formatter. As a result, KtLint sometimes is forced to fix formatting to reproduce erroneous styling of IntelliJ IDEA Default formatting. Some of those issues have been reported to Jetbrains issuetracker several years ago and are still not picked up.

The new codestyle KtLint Official will have following characteristics:

  • Tries to match with IntelliJ IDEA Default formatting but may produce code which will be formatted differently when applying the IntelliJ IDEA default formatting.
  • Primarily adheres to the Kotlin Coding Conventions. If Android's Kotlin styleguide contains additional rules which are not conflicting with the Kotlin Coding conventions, those will be used. The Ktlint Official codestyle will be opinionated and might even contain rules like indentation of raw string literals (auto-indent bodies of multiline strings with .trimIndent() #925) which by default will be disabled in the other codestyles.
  • The initial release of the KtLint Official codestyle will use an opt-in model, meaning that this codestyle has to be set explicitly in the .editorconfig (or via a CLI parameter). The intent however is that this becomes the default codestyle for Ktlint from which user have to opt-out out by explicitly configuring another codestyle.

Currently, the main differences between the Kotlin and Android codestyles in KtLint are limited to different default values for the .editorconfig properties. With introduction of the 'KtLint Official' codestyle, some parts of the rules in KtLint might actually get a different implementation.

Please checkout the issues which potentially will be solved in ktlint-official-codestyle . Please drop a comment with your thoughts. If you have another candidate for the Ktlint Official codestyle then please create a separate issue and it will be tagged as ktlint-official-codestyle .

@paul-dingemans paul-dingemans added this to the 0.49.0 milestone Nov 6, 2022
paul-dingemans added a commit to paul-dingemans/ktlint that referenced this issue Dec 18, 2022
…fficial` code style), `intellij_idea` (replacement for old `official` code style) and `android_studio` (replacement for old `android` code style).

Closes pinterest#1699
@bcmedeiros
Copy link

Some of those issues have been reported to Jetbrains issuetracker several years ago and are still not picked up.

Do we keep a list of those somewhere?
Being Jetbrains the main company behind Kotlin, I'd expect its own IDE to comply with the Kotlin Coding Conventions.

@paul-dingemans
Copy link
Collaborator Author

No, I am not aware of a list of such issues. References are scattered in code and documentation, and in GitHub issues or pull requests.

paul-dingemans added a commit to paul-dingemans/ktlint that referenced this issue Jan 18, 2023
* Add code style `ktlint_official` (functionally equivalent with old `official` code style), `intellij_idea` (replacement for old `official` code style) and `android_studio` (replacement for old `android` code style).

Closes pinterest#1699

* Format project itself to "official ktlint" codestyle.

* Add Gradle "ktlint format" task.

* Ensure that the subcommand generateEditorConfig, gitPreCommitHook and gitPrePushHook can receive the code-style before or after the subcommand and print error in case the code style option is not specified explicitly.

* Add option to KtLintRuleEngine to ignore the '.editorconfig' on the file system. Unit test classed have to obey to '.editorconfig' settings of the project. Code snippets inside those unit tests should not be influenced by the '.editorconfig' settings of the project but only by properties which have been explicitly defined in the unit test.

* Files used for CLI tests contain lint violations on purpose in order to validate the tests. The tests may not be affected by the ".editorconfig" files which are used to lint/format the code of the Ktlint project itself. Neither may the ".editorconfig" files of the project lead to changing the input files for the tests. Files used as input for the cli test use the ".test" extension so that those files can be separated from the actual project files.
 The tests that used the "filename" rule have been replaced with the "no-wildcard-imports" rule. Reason for this is that the "filename" rule contains a hardcoded check that excludes all files not ending with a ".kt" extension.

* Do not add the (first line of the) body expression on the same line as the function signature in case the max line length would be exceeded. `function-signature`.

* Do not add the first line of a multiline body expression on the same line as the function signature in case function body expression wrapping property is set to `multiline`. `function-signature`.
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
2 participants