It is not easy for new contributors to ensure that their IDE is configured accordingly to the required code style. The only way right now is to carefully read Google Java Style Guide and change their IDE configuration manually. Or to remember to run gradlew goJF before commit.
The easier approach would be to provide .editorconfig file which would apply desired formatting rules automatically.
Is there an editorconfig file that matches the style/format that matches what goJF requires/generates? Is so, then I'm 100% in favor of this.
I could not find it in 5 minutes, but I am willing to compose one.
Isn't .editorconfig most useful for just the basics like line endings and tabs vs spaces?
@Oberon00 at least IntelliJ IDEA provides much more: https://blog.jetbrains.com/idea/2019/06/managing-code-style-on-a-directory-level-with-editorconfig/
I've been able to get it close, but not exactly the same. Two things i haven't figured out:
Constructor() {}@jkwatson will you share your result with us? :)
We should document goJF in contributing guidelines and probably what it into format make target. I always forget the name of gradle task.
What about adding goJF as a pre-requisite of compileJava in the gradle.build file?
I would even go further and add this as git pre-commit hook
I personally would like to have it as a pre-commit hook or similar, but don't have it as a requirement of compileJava, i.e. quite often when refactoring or prototyping I get annoyed/distracted by the style messages/errors.
In any case, that's a different conversation. Lets do the .editorconfig change and document the goJF case (in a separate commit) as Pavol suggested.
@carlosalberto what I meant was not to call the verify task but the automatic reformatted. This way, every time a compilation is performed, it is automatically formatted correctly.
@thisthat I personally still don't like that. My 'dead' code when refactoring is suddenly gone automatically. Wouldn't love that ;) In any case, shall we fill a new issue? We can iterate on our options there and decide what's the best trade-off ;)
@thisthat I personally still don't like that. My 'dead' code when refactoring is suddenly gone automatically. Wouldn't love that ;) In any case, shall we fill a new issue? We can iterate on our options there and decide what's the best trade-off ;)
Actually, that's a fair point! :smile: You convinced me!
Here's what I have, which is close, but not perfect. I've also just hooked up a pre-commit hook to do the formatting as a fail safe.
Here's the pre-commit hook that I've started using.
We are enforcing goJF in auto-instr-java also, and these Intellij plugins have been working well for me:

Problem with plugins is that every developer has to install them, and to know that they have to install them. EditorConfig works out the box with IntelliJ.
Having .editorconfig is a good start. Then we can add a docs section on how to configure commonly used plugins/hooks :)
I spent a bunch of time in IDEA yesterday trying to perfectly replicate the google java format, and i don't believe it's possible with the current set of options, unfortunately. So, even with a .editorconfig, you can/will commit code that doesn't match what the verifier requires. Unless you put in a pre-commit hook, or do it manually, of course.
@jkwatson Thanks for the file. I think it is a great start which will make a life of new contributors significantly easier :)