Allow more code style configurations

[wolfs]

To configure the same code styles we configure now in the gradle/gradle build, there are still some configurations missing. Compare https://github.com/gradle/gradle/blob/5fee26b5895389e7fc9c6d3c6e3a87d79eca45c4/buildSrc/subprojects/ide/src/main/kotlin/org/gradle/gradlebuild/ide/IdePlugin.kt#L590-L637 vs https://github.com/gradle/gradle/blob/5fee26b5895389e7fc9c6d3c6e3a87d79eca45c4/buildSrc/subprojects/ide/src/main/kotlin/org/gradle/gradlebuild/ide/IdePlugin.kt#L641-L668

I think the following is still missing:

General:

• set the line separator (not super important, but I think we should be able to set this to \n) Let's use .editorconfig for this.
• enable formatter tags
• what is the replacement for USE_SAME_INDENTS?

Java/Groovy

• Names count to use static import with *

What about Kotlin? How can we set some code styles for Kotlin?

[eskatos]

I recently opened #39 for Kotlin code style configuration

[lptr]

set the line separator (not super important, but I think we should be able to set this to \n)

This can be controlled via .editorconfig, too.

[wolfs]

Good point. Let's use .editorconfig then.

[nskvortsov]

The Idea will support .editorconfig anyway. Duplicating these settings in codestyle does not make much sense. codestyle might be deprecated and removed in future releases

[wolfs]

That probably means that USE_SAME_INDENTS can be dropped in favor of .editorconfig?

So what is left is

• enable formatter tags
• Names count to use static import with * for Groovy/Java code style

[eskatos]

codestyle might be deprecated and removed in future releases

.editorconfig supports a range of options but there are things it doesn't that I would consider important like imports organization, blank lines, wrapping etc..

[hakanai]

Brace position is the huge missing item IMO.

[bric3]

Other ideas and settings like but those appear to be in the IDE settings only

• Add unambiguous imports on the fly
• Optimize imports on the fly
• Exclude from import and completion

For style settings I'm not sure the current codeStyle section can map the richness of the available settings, not to mention possible evolution and changes in the IDE.

<code_scheme name="java-style-settings" version="173">
  <option name="LINE_SEPARATOR" value="&#xA;" />
  <option name="FORMATTER_TAGS_ENABLED" value="true" />
  <option name="SOFT_MARGINS" value="80,120" />
  <JavaCodeStyleSettings>
    <option name="ALIGN_MULTILINE_ANNOTATION_PARAMETERS" value="true" />
    <option name="INSERT_INNER_CLASS_IMPORTS" value="true" />
    <option name="CLASS_COUNT_TO_USE_IMPORT_ON_DEMAND" value="99" />
    <option name="NAMES_COUNT_TO_USE_IMPORT_ON_DEMAND" value="99" />
    <DO_NOT_IMPORT_INNER>
      <CLASS name="Builder" />
      <CLASS name="Factory" />
    </DO_NOT_IMPORT_INNER>
  </JavaCodeStyleSettings>
  <codeStyleSettings language="JAVA">
    <option name="ALIGN_MULTILINE_CHAINED_METHODS" value="true" />
    <option name="ALIGN_MULTILINE_PARAMETERS_IN_CALLS" value="true" />
    <option name="ALIGN_MULTILINE_BINARY_OPERATION" value="true" />
    <option name="ALIGN_MULTILINE_ASSIGNMENT" value="true" />
    <option name="ALIGN_MULTILINE_TERNARY_OPERATION" value="true" />
    <option name="ALIGN_MULTILINE_THROWS_LIST" value="true" />
    <option name="ALIGN_MULTILINE_EXTENDS_LIST" value="true" />
    <option name="ALIGN_MULTILINE_PARENTHESIZED_EXPRESSION" value="true" />
    <option name="ALIGN_MULTILINE_ARRAY_INITIALIZER_EXPRESSION" value="true" />
    <option name="BINARY_OPERATION_SIGN_ON_NEXT_LINE" value="true" />
    <option name="SOFT_MARGINS" value="80,120" />
  </codeStyleSettings>
</code_scheme>

[bric3]

Seems like this one can be dropped as the new way appear to be .editorConfig, see

1. https://youtrack.jetbrains.com/oauth?state=%2Fissue%2FIDEA-69685
2. https://blog.jetbrains.com/idea/2019/06/intellij-idea-2019-2-eap3-code-style-per-scope-refreshed-code-completion-popup-and-more/

[hakanai]

Interesting, though now we have a new problem of how to get that file created from the build. Is there a plug-in for that one already? :)

[bric3]

@trejkaz I think one just has to configure it in IDEA once and store it in the root of the repository. IJ will then automatically pickthis file to configure the style of the repository / project.

[hakanai]

If I have to do it once per repository then that is hardly once. :/

[bric3]

@trejkaz you can copy it to each repository. I'm not sure how this plugin could have help in your situation anyway, since this must be applied on each buildscript.

[hakanai]

The current limited code style settings are in the Gradle config, so they don't have to be done in every build script. You can (and we do) do it from a common plugin all projects import.

[nskvortsov]

Please, use .editorconfig for this purpose

[hakanai]

Can we have a way to automatically generate .editorconfig then so that I don't have to copy the config into every single build manually?

[nskvortsov]

@trejkaz you are looking for the ability to share code style across many projects, am I getting it right?

[hakanai]

Not just code style, just IDEA settings in general. Code style is one such setting, inspections is another.

When I looked at editorconfig, it was overly simplistic, and seemed like it only dealt with indent level and didn't even have a way to set brace style, even though that is a more important thing to be able to configure. And it never made sense to me why the basic style of the file should be in a separate file from all the other editor configuration.

[nskvortsov]

.editorconfig contains much more than indent level, and also there are Intellij IDEA-specific properties in it.

[hakanai]

Certainly there are editor-specific things in there now, which is a move towards editors hopefully standardising common things in the future.

But yeah, we are using idea-ext to apply common settings across many separate projects, so we might have to end up making a plugin to generate .editorsettings or something.

[bric3]

@nskvortsov Does IntelliJ IDEA .editorconfig extensions supports settings such as Optimize imports on the fly and the import exclude that we can configure in Auto Imports.

[nskvortsov]

@bric3 .editorconfig supports flags and settings visible in Editor -> codestyle section. Auto Imports settings are not among them.

[bric3]

@nskvortsov That what I thought. In this case I think this may be worth it to make idea-ext to support this kind of settings.

[rgoldberg]

Would the following be a useful way to avoid having to copy an .editorconfig into every project?

Add a setting into idea-ext that accepts a path to an .editorconfig that it will apply to the project.

An .editorconfig can be included in a custom plugin that applies idea-ext using that included .editorconfig.

If idea-ext is applied with a .editorconfig to a project where an .editorconfig exists in the standard location in the file system for the project, then you can do one of the following (possibly configurable as another setting in idea-ext, or possibly always using the same mechanism):

1. fail the build
2. use file system .editorconfig, ignoring plugin .editorconfig (this makes more sense than 3)
3. use plugin .editorconfig, ignoring file system .editorconfig (this makes less sense than 2)
4. cascading settings, where settings in file system .editorconfig override conflicting settings in plugin .editorconfig (this makes more sense than 5)
5. cascading settings, where settings in plugin .editorconfig override conflicting settings in file system .editorconfig (this makes less sense than 4)

[hakanai]

That seems like it would work. I'd probably want the path to be a URI so that it can be included inside the plugin jar itself.

We'd probably go with mechanism 4, or potentially 1.

[rgoldberg]

A URI seems like a good idea. (I was thinking of a path to a resource, but a URI should be more flexible, right?)

I prefer the following options, in decreasing order of preference:

• defaulting to 4, but having a setting to select between these 5 options
• 4
• 2
• 1

Any of them would be preferable to copying a file everywhere.

[wolfs]

The idea-ext-plugin, or any other plugin, could copy the .editorconfig from a known location into the project if it doesn't exist already. This way, IDEA would pick it up and it is very easy to add a customized one to the current location. The idea-ext-plugin isn't really necessary for doing this.