Introduce unified code formatting for all IDEs

[tobous]

Currently, the code formatting rules used in Eclipse do not match the code formatting rules used in IntelliJ. This leads to an unevenly formatted codebase. Furthermore, this can lead to edit-wars/unnecessary formattings when working on code of an IDE specific part of Saros with a different IDE.

As far as I can tell, all project except "intellij" are formatted according to the Eclipse formatting rules.

[stefaus]

I think we have two options for this.

1: Use this Plugin to import the existing Saros Eclipse Format Rules into IntelliJ.
I've tested it, but it has some problems with formating using the existing Saros config.
I think this occures because the Saros format rules File is to old and this would change with using 4.6+ Eclipse (and update the existing rules file).

But as I already expressed at the Stand-Ups I don't like the current formatting rules.

Therefore my preferred option 2: Use the google java format rules. This obsolete discussions about format details, brings a widely used ruleset and it comes with a stand alone formatter.
https://github.com/google/google-java-format

They provide Plugins to format code directly in Eclipse and IntelliJ.
It works from the CLI making it IDE independent and even provide gradle support, so we could check format violations for each check in.

[m273d15]

Option 2 looks good! The rule set is immutable and can be checked during the CI process 👍

[tobous]

That sounds like an interesting solution, but we should discuss the contained formatting when considering using predefined immutable settings.

For example, I am not really happy with their default indentation width being 2 spaces (instead of 4).

[stefaus]

Yes, the indentation was also unusual to me.
But the gain: Block indentation (+2 spaces) is easier to distinguish from continuation lines (+4 spaces).

Changing the format rules would need a project fork, making things difficult.

[srossbach]

Why do we need a fork ? We could modify the source to our needs, compile it and put the result in one of our Git Repositories. That would at least ensure that every uses the same version.

[tobous]

As I already said, I don't like that the code formatting enforced by "Google Java Style" is not configurable/adjustable.

An alternative would be Checkstyle (GitHub, Website). I have to read up on it more, but from the looks of it, it allows to set up code style profiles that can be enforced at build time. (There is a pre-build profile that imitates the Google Java Style format that would be adjustable.). This can be done be integrated into our gradle build through a plugin, meaning it could be done automatically and would fail the build if certain criteria of the code style were not met.

The main drawback of Checkstyle is that, as the name already suggests, it just checks the code style. It is not a standalone formatter. For this we would still have to rely on IDEs. Both IntelliJ and Eclipse have an option to import Checkstyle configurations into the local code formatter (I only tried it with IntelliJ).
I don't think this can be done IDE independent. (The website mentions that there is a Vim plugin, but it has been abandoned since around 2003.)

This means Checkstyle is not a perfect solution either, but I think it is worth a consideration. (It is defensively a better solution than patching/forking the google java style plugin in my eyes.)

For me, not being able to format the code without an IDE is not a problem, but I don't know what your workflows are like. What are your opinions on using Checkstyle?

[srossbach]

I think without a default formatter there is to much room for edit wars (e.g one prefers short line, the next one does not even care etc.). And marking a build as failed because of some violation regarding the layout of the code is in my opinion a very bad idea.

[tobous]

What do you mean with "without a default formatter"? With a codestyle profile imported into the IDE formatters, we would have basically the same situation that we have currently (especially since you have to import the eclipse profile manually currently anyway, meaning basically nothing would change except you would also have to install the checkstyle plugin). The files defining the code style would still be shared through the git repository. The only difference to the current situation would be that we have a configuration that can be applied to both IDEs and that can be checked on the build server.

And regarding failing builds: If the codestyle settings are sensible, I don't see why we shouldn't fail builds that don't meet the defined code formatting, at least on the build server. This saves us the hassle of discussing basic formatting during reviews. If the guidelines are not met, the server gives a negative review for us. The only important part would be that these checks are only run after the normal build (as build errors should take precedent in my opinion) and that it is communicated clearly to the developer that the (travis) build failed because the formatting was wrong.

For local builds I understand your point that failures due to wrong formatting could be counterproductive. For checking the formatting locally, we could use a gradle task to call checkstyle or use the IDE plugins.

[srossbach]

So do you mean we should use Checkstyle to verify that the developers are using a specific code formatter (like the Google one) or do you suggest only to use Checkstyle to make a build fail if the code have some serious formatting issues ? In my opinion it is still frustrating if you build fails on Travis because of formatting violations when you do not have a formatter available. So it basically the workflow could look like this:

while CheckStyle is not happy on your local code layout : do some modifications

result = ?

It is like when you are enforcing JavaDoc

/** Make tool XYZ happy so the build will not fail **/

public T methodWithVeryComplexLogic(....)

[tobous]

I would suggest to use Checkstyle to

• Define a specific code formatting that is shared through the git repo
• Allow developers to check for this code formatting locally (through a gradle task or IDE plugins)
• Allow developers to format their code according to these defined formatting rules iff they are using an IDE that supports such a functionality (IntelliJ and Eclipse both do)
• Fail Travis builds if the defined code formatting is not met when pushing to the repository.

But we would have to test how well these code formatting rules are applied by the IDE formatters before enforcing them for Travis builds. I ran into an issue where the automatic formatting was in conflict with the defined rules. But this might have been a problem with my setup.

[m273d15]

I think without a default formatter there is to much room for edit wars (e.g one prefers short line, the next one does not even care etc.).

I totally agree. As long as the formatting is consistent for all IDEs (Eclipse, IntelliJ, Vim/Emacs) I am fine. Everybody, has its own taste and discussions about personal taste are tedious. I think the easiest solution is to create poll where we vote for "immutable google style" or "customized formatting style". The question whether the formatting should be checked during the CI process is independent of this question.

In my opinion it is still frustrating if you build fails on Travis because of formatting violations when you do not have a formatter available.

If we want to you use the corresponding gradle plugin everybody would be able to run the formatter. Furthermore, everybody could use the standalone formatter (either Google format or checkstyle) in a git hook. I think we already do this for JavaScript since #264 .

It is like when you are enforcing JavaDoc /** Make tool XYZ happy so the build will not fail **/

I don't see this point if we talk about formatting, because the formatting is adjusted automatically.