Most projects, that I work with nowadays, have a defined code standard that includes how the code should be formatted. That is great and improves code quality a lot... if followed!

A single person, in the project, can lower the quality significantly by not formatting the code correctly. If such code is not blocked, from making it into shared branches, you will have the choice of keeping it or fixing it. This is a problem that I find incredibly annoying!

  • Keeping it means you have to live with faulty formatted code. If some developers use something like save actions in Eclipse then they will have a hard time keeping the lines unchanged when working on the file.
  • Re-formatting it in a new commit makes it harder to maintain the project because things like git blame will show the re-format commit, not the original feature commit.

The most common solution to this, among the clients I've been working with, is to use a code style defined in Eclipse. Along with save actions. The code style is imported to Eclipse from an XML-file and some clients also use Workspace Mechanics to setup save actions properly.

Defining the code style in Eclipse is a very bad idea:

  • All people are not productive in Eclipse, some might for example be using InteliJ or NetBeans. They will have to have Eclipse installed just to use it for formatting.
  • The semantics of the settings in the code style may change between versions of Eclipse (I have seen it!). Then you may start getting unnecessary diffs in commits after an upgrade.
  • There is no way, as far as I know, to verify Eclipse-formatting as a step in a continuous integration flow. While it is easy for a reviewer to see that brackets are incorrectly positioned, other things may not be as obvious.

Google Java Format

If it is up to me, I choose Google Java Format. Because:

  • There are plugins for Gradle and Maven so that it can easily be integrated in the build process. Applied when building and verified in continuous integration.
  • It takes all decisions regarding formatting of Java code. It can even optimize imports, sorting and removing unused imports.
  • All decisions in this code style is carefully taken considering how diffs will appear in files where it is applied.
  • The code style, and the tool support for that, is completely separate from any IDE used. You can let the developers use whatever IDE they want. The important thing is what they produce, the code, which should have no references to any IDE.

I use these in different projects:

  • FMT Maven Plugin. You just need to add it to the pom.xml and it will format the code at compile time. It includes a validate attribute that can be used in continuous integration, perhaps with a build property, to validate that the code is formatted correctly.
  • Google Java Format Gradle Plugin. You just need to add it to the build.gradle and it can format the code at compile time with something like compileJava.dependsOn 'googleJavaFormat'. It adds a verifyGoogleJavaFormat task to be used in continuous integration to verify formatting.

A common problem when auto formatting coding is with newlines. I use phantom comments to deal with that. Just add // at the end of the line, like this, to force the formatter to keep it that way.