google-java-format icon indicating copy to clipboard operation
google-java-format copied to clipboard

Fix google-java-format reformatting code formatted by Android Studio for Platform when running with AOSP style

Open josh-gordon-fb opened this issue 8 months ago • 7 comments

Google-java-format when using AOSP style will reformat code that was already formatted by Google's Android Studio for Platform IDE (and vice versa). Both styles are compliant with the guidelines specified in AOSP Java code style for contributors. This prevents formatters from clobbering each other by updating google-java-format to be compliant with Android Studio for Platform's format when running with --aosp. No changes are made to the standard format.

Tested by formatting with Android Studio for Platform then google-java-format over multiple projects in AOSP and diffing to confirm no changes. All unit tests pass.

josh-gordon-fb avatar Apr 07 '25 20:04 josh-gordon-fb

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

google-cla[bot] avatar Apr 07 '25 20:04 google-cla[bot]

Google-java-format when using AOSP style will reformat code that was already formatted by Google's Android Studio for Platform IDE (and vice versa). Both styles are compliant with the guidelines specified in AOSP Java code style for contributors.

Preserving the formatting of existing code is not a goal of this project, see: https://github.com/google/google-java-format/wiki/FAQ#why-didnt-it-leave-my-perfectly-valid-code-alone

The alternatives I'd recommend are to either standardize on one formatter for a particular codebase, or to run google-java-format on changed lines to avoid re-formatting unmodified code that isn't formatted in its style.

cushon avatar Apr 11 '25 00:04 cushon

Preserving the formatting of existing code is not a goal of this project, see: https://github.com/google/google-java-format/wiki/FAQ#why-didnt-it-leave-my-perfectly-valid-code-alone

My goal here isn't to make google-java-format preserve the formatting of existing code. My goal is to make google-java-format's existing --aosp flag to match the style enforced by Google's IDE for AOSP.

The alternatives I'd recommend are to either standardize on one formatter for a particular codebase, or to run google-java-format on changed lines to avoid re-formatting unmodified code that isn't formatted in its style.

Android Studio for Platform is "the official IDE for Android platform development", but its formatter can't be run in CI which makes standardizing on it difficult. I don't think any sort of compatibility with other formatters is necessary, but we should fix the unintentional behavior of google-java-format not matching Google's IDE for AOSP code.

josh-gordon-fb avatar Apr 15 '25 00:04 josh-gordon-fb

Maybe you want to use the google-java-format plugin for Android Studio? It will override the built-in formatter so you don't have two different formatters competing with each other.

plumpy avatar Apr 15 '25 14:04 plumpy

I think the default Android Studio behaviour is using IntelliJ's formatter with a configuration to follow AOSP style. This is related to the discussion of java-google-style.xml in #695. The source of truth for AOSP style is their style guide, which google-java-format follows. The IntelliJ formatter configuration is less authoritative than the style guide, and making google-java-format more similar to that behaviour isn't a goal.

cushon avatar Apr 15 '25 15:04 cushon

@plumpy

Maybe you want to use the google-java-format plugin for Android Studio? It will override the built-in formatter so you don't have two different formatters competing with each other.

It's my understanding from the style guide that users are expected to adhere to the configuration that Google generates (either through ASfP defaults or aidegen): We expect that as IDE users work on the code, imports in all packages will match this pattern without extra engineering effort. If we use GJF as a plugin, we diverge from the configuration enforced by Google's AOSP maintainers.

@cushon

The source of truth for AOSP style is their style guide, which google-java-format follows

I'm not sure this is correct. I don't think GJF complies with AOSP's style guide, even with the --aosp CLI flag. The style guide is a mix of semantic rules and syntactic ones, but of the very few syntactic rules listed I already see some divergence. Likely not exhaustive, but here's a few:

  • ~~GJF import orderings and spacing don't match the style guide~~ EDIT: this is user error on my part, I see where AOSP is handled in ImportOrderer (I seem to recall some issues last year with comments interspersed in the imports, but I can't reproduce the issue locally right now)
  • Annotation ordering doesn't match the style guide

jpumford avatar Apr 15 '25 22:04 jpumford

It's my understanding from the style guide that users are expected to adhere to the configuration that Google generates (either through ASfP defaults or aidegen): We expect that as IDE users work on the code, imports in all packages will match this pattern without extra engineering effort.

I read that section as specifically talking about a style for imports, not as saying that the source of truth for all style decisions is IntelliJ's formatter with the AOSP configuration.

GJF import orderings and spacing don't match the style guide (I seem to recall some issues last year with comments interspersed in the imports, but I can't reproduce the issue locally right now)

The formatter should be following AOSP import order when --aosp is configured (as long as --skip-sorting-imports is not also configured). If you're able to reproduce this, please file a bug.

Annotation ordering doesn't match the style guide

Do you have a specific example?

cushon avatar Apr 16 '25 16:04 cushon