Add new codestyle KtLint Official
#1699
Labels
Milestone
Comments
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
This was referenced Dec 18, 2022
Do we keep a list of those somewhere? |
|
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`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 Officialwill have following characteristics:Ktlint Officialcodestyle 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.KtLint Officialcodestyle 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
.editorconfigproperties. 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 Officialcodestyle then please create a separate issue and it will be tagged as ktlint-official-codestyle .The text was updated successfully, but these errors were encountered: