RFR: 7903479: JMH: Add .editorconfig so IDEs would pick up the common settings automatically: indent, trim whitespace [v2]

[Vladimir Sitnikov]

On Wed, 31 May 2023 08:04:55 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> See https://bugs.openjdk.org/browse/CODETOOLS-7903479
>> 
>> I tried re-format random files from JMH, and they either kept intact, or the changes were minimal.
>
> Vladimir Sitnikov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trigger Actions CI

Thank you for the review.

TL;DR: the whole point of adding `.editorconfig` is to make IDEs autoconfigure in such a way that the produced patches are more likely to pass CI and review from the first try.

>Enforcing the formatting seems to gain little here.

Please review 1 (tab vs space), 2 (newline at the end of the file), and 3 (trailing whitespace) below.
The project already enforces those checks, and it is really painful for contributors to adhere to those checks, especially when IDEs can fix those things automatically provided there's a trivial `.editorconfig`.

>How ubiquitous it is to provide .editorconfig? Is this what projects do these days as the matter of course?

I think `.editorconfig` is the only (?) standard way to configure IDE defaults.

> Enforcing the formatting seems to gain little here.
> Maybe I am missing a point here? 

Let me put a couple of examples:

1) In `checkstyle.xml` you have a check that forbids the use of `tab` character for indentation: https://github.com/openjdk/jmh/blob/47f651b72d05c2c335f8ced5ed33f2fb0dd26720/jmh-core/src/main/resources/checkstyle.xml#LL203C13-L203C13
  However, at the same time, you provide no ways for the contributors to account that convention.
  The suggested `.editorconfig` enables IDEs to pick up the setting automatically, so users don't need to change tabs to spaces or whatever manually.

2) In `checkstyle.xml` you have `NewlineAtEndOfFile` check that requires, well, new line at end of file: https://github.com/openjdk/jmh/blob/47f651b72d05c2c335f8ced5ed33f2fb0dd26720/jmh-core/src/main/resources/checkstyle.xml#L204
  That carries the same issue: checkstyle verification is there, however, there's no way to automatically fix it.
  I suggest listing that convention in `.editorconfig` so IDEs would automatically add the trailing newline, so the contributors won't need to bother with checkstyle violations. It would just work automatically.

3) In OpenJDK overall, and in `jmh` in particular, you have "trailing whitespace check" via jcheck: https://github.com/openjdk/jcheck/blob/e0ef112adf94aed4a7a6973513584f0f0f1e6297/jcheck.py#LL177C37-L177C37
  It is insane to require users to manually trim the trailing whitespace when the tools can just do it automatically.
  What I suggest is to make it easier for the users to contribute: the IDE would automatically trim the whitespace, so users would not be distracted by random `trailing whitespace` violations by `jcheck`.

4) I believe the overall code should look as if it was written by a single person, so when making contributions, it would be nice to have a style of contributions that resembles the current code style of the project.
Currently, there's no way to know if the style is similar or not. Every time I contribute, I have to manually look around to see how similar things were implemented in a nearby code.
  What I suggest is to add several `ij_...` formatting options, so the ones who use IntelliJ for contribution, could benefit from an automatic style that more-or-less matches the current code. I do not really understand why would you want to make it harder for the contributors to figure out the preferred style. I'm fine if you ok to accept multiple code styles, however, why would you make it harder for the contributors to format the code that looks good side-by-side with the existing code?

-------------

PR Comment: https://git.openjdk.org/jmh/pull/105#issuecomment-1598504343