+1 to Spotless, Checkstyle, and RAT.
Spotless is great for having a consistent style in the code. Checkstyle
is good for enforcing code standards like class level comments. Rat is
useful for license checks.
Concerning the formatting changes, I think this is the ideal point in
time to reformat the code. Yes, it comes with some obfuscation of the
Git history but IMHO it's worth it.
-Max
On 10.10.20 15:51, [email protected] wrote:
Hi,
For Apache project, we are using the apache-pom-parent:
https://github.com/apache/maven-apache-parent/blob/master/pom.xml
<https://github.com/apache/maven-apache-parent/blob/master/pom.xml>
There is some usefull plugin definition as rat and release profile.
We can add a quality check maven profile in our CI and a documentation
in the contribution page for the users to help them to validate their
PRs locally.
For the spotless maven plugin, I already used it in some project but at
the init. We have to keep in mind that the first time we will run it, it
will update all of the code source, so it can be hard to check some diff
between new and old PRs.
Just my 2cts ;)
regards,
François
[email protected]
Le 10/10/2020 à 15:20, Hans Van Akelyen a écrit :
Hi All,
We have received some questions about code style and formatting. Currently
we do not have guidelines for code style and haven't really been thinking
about this yet. To increase our code quality and lower the bar for
contributions, developer guidelines should be created as soon as possible.
A proposal has come in the form of a PR [1] to implement the spotless maven
plugin, this plugin can be used to format code using the Google java style
guide [2] and also add the correct header to a file.
This plugin combined with formatter plugins for Eclipse and Intellij [3]
allows all developers to format code in the same way, avoiding PR merge
hell because the formatting of the files changed.
We can then also include/activate checkstyle and RAT maven plugins in our
PR CI builds to check if the code passes our coding standards.
This mail is to see if there are objections against using Google java style
guide, if there are no objections we will move forward to test if all works
as expected, write up a developer guide and do an initial check/format of
all our code.
Hans
[1] https://github.com/project-hop/hop/pull/290
[2] https://google.github.io/styleguide/javaguide.html
[3] https://github.com/google/google-java-format
