We use the Google Java formatter in Spinnaker, and while I know some of my teammates despise the particular code style chosen there, my preference is consistency over anything. A deterministic formatter would be best for avoiding merge conflicts. If we adopt a formatter, as long as it’s IDE-agnostic (like the GJF one is), then I’m alright with it.
> On Sep 20, 2023, at 8:29 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > Hmm... interesting but I can't help but think that we are making our > build more complex by jumping through hoops to fix problems of our own > making: We already use spotless in the builds. Now we want to use > OpenRewrite but that makes a "mess", so now we want to use _another_ > plugin to fix that, that in itself is a mess IMO. My favorite way to > deal with formatting and refactoring is to use Eclipse which has a > large set of formatting configuration options and clean-ups. Not > everyone uses Eclipse, so sharing an Eclipse or any other IDE > formatter config might be pointless. I think we need to keep > refactorings OUT of builds, formatting is already weird enough. > > Gary > > On Wed, Sep 20, 2023 at 1:45 AM Piotr P. Karwasz > <piotr.karw...@gmail.com> wrote: >> >> Hi, >> >> Right now our Spotless configuration just specifies the lines endings, >> forbids tabs and sorts the imports. If we want to apply some >> OpenRewrite rule to the codebase (e.g. migrate all string >> concatenations to parameterized logging or migrate JUnit4 to Junit5), >> we need a deterministic formatter to clean up the mess OpenRewrite >> leaves behind. >> >> On my personal projects I've bee playing with Google Java format[1] >> for some time and it basically corresponds to what we already use >> except: >> >> * it has a non-configurable indentation of 2 spaces. >> >> There is also a Palantir Java format[2], which is as far as I can tell >> also non-configurable (which is a feature, not a problem). Both have >> maintained Eclipse and IntelliJ plugins. >> >> On the other hand of the spectrum there is an Eclipse formatter, which >> is fully configurable and apparently has an IntelliJ plugin[3]. This >> is the one I used at my dayjob, but it lead to months of discussions, >> complains about the settings and a list of trick and tips on how to >> change the formatting with comments. We also had a minor problem with >> import sorting: >> >> * the formatter does not sort imports, so we used Spotless to do it. >> However Spotless and the Eclipse IDE use a different collation, which >> generated some conflicts. >> >> What do you think about enforcing a deterministic formatter on our code? >> >> Piotr >> >> [1] https://github.com/google/google-java-format >> [2] https://github.com/palantir/palantir-java-format >> [3] >> https://plugins.jetbrains.com/plugin/6546-adapter-for-eclipse-code-formatter
