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 blamewill 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. 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
I sincerely do not care how the code is formatted when I come to a new client. Tabs or spaces, brackets on same or new line... it does not matter. What matters is that you agree on something, anything!, and follow it. That is why, if it is my decision, I choose Google Java Format.
There is the library and also plugins for Maven and Gradle. This means 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.xmland 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.
- Formatter Maven Plugin. You just need to add it to the
pom.xmland it will format the code at compile time. It includes a validate goal that can be used in continuous integration to validate that the code is formatted correctly.
- Google Java Format Gradle Plugin. You just need to add it to the
build.gradleand it can format the code at compile time with something like
compileJava.dependsOn 'googleJavaFormat'. It adds a
verifyGoogleJavaFormattask 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.