Actualize Eclipse Che Java coding standards

[skabashnyuk]

The goal of this issues is to revise our existed guidelines
https://github.com/eclipse/che/wiki/Coding-Guidelines and adapt
it to realities and the challenges that we have today.

As for me I can see such problems

1. Unfortunately, Java has no single format standard like GO lang has and there is no single tool that all have to follow.
2. Existed document is quite a long read and a bit hard to follow.
   More general: people want that this thing has to work some how, but not to pay a lot of attention to it.
3. We want some kind of automation that can check if coding standards has followed.
4. We don't to spend a lot of time to support different tools our format. Like config for Eclipse or config for IntelliJ, etc.

I'm proposing following direction.

1. We can use Google Java Style Guide https://google.github.io/styleguide/javaguide.html
2. We can reformat existed code according to new rules.
3. We can use https://github.com/google/google-java-format https://github.com/coveo/fmt-maven-plugin tool to automate format checking as we have with a license checking.
4. We can reuse existing configuration of Google formatter for Eclipse IDE, Eclipse Che and IntelliJ

[benoitf]

AFAIK we use 4 spaces indent in Java code while google is using 2 spaces indent. Using option 1. will change impact almost all lines of Java files

[skabashnyuk]

yes.

[benoitf]

@skabashnyuk could you describe more the yes ?

• we will use a custom template to avoid that change causing a lot of merging troubles.
• we will change all codes to stick to google ?

because when I read "we can" it seems to be still an option, not the way to go.

[skabashnyuk]

No our plan to use " Google Java Style" as is without modification.

[benoitf]

I didn't see public discussion around the "our plan"

[garagatyi]

For sure it will impact whole code database. I suppose even without changing indentation from 4 to 2 spaces we will get huge amount of changed lines

[garagatyi]

Issues and PRs are public and discussion is allowed here

[benoitf]

This kind of change should be discussed publicly on mailing lists.

[benoitf]

Especially when the word "our" is used while I saw no previous discussion before.

[skabashnyuk]

Ok. Guys. The main idea is to not to have any "holly wars" around format and reuse something popular as is without a single modification. Because when we can use some automation like this https://github.com/coveo/fmt-maven-plugin

@benoitf what do you propose?

[garagatyi]

Nothing is committed yet, so you can drive the discussion now. I don't see a problem here.
I do believe that creation of a PR or issue is allowed without sending a mail to che email list.

[benoitf]

@skabashnyuk my point was more on the process. Informing the community first, grab feedback about expectations of users, propose options, etc. Instead of a list of tasks in a github issue.

[skabashnyuk]

10 days is not enough to inform?

[benoitf]

@skabashnyuk IMHO Informing the community is not creating an issue on github.

[benoitf]

on the question: I mainly see that the proposed solution is only targetting java files. But Eclipse Che "coding standards" is also for other type of files like : XML, TypeScript. I saw nothing on the description about that part while users can contribute to other files than "Java".

I heared in a previous meeting that EditorConfig could be used but I don't see it in the list. (because here it targets only Eclipse IDE, Che and Intellij

[skabashnyuk]

yes. You are right. I'll change the scope of this issue to Java only.

[benoitf]

but why isn't it a broader scope that only Java ?

[skabashnyuk]

I doubt that this is potentially resolvable in close future. Don't want to take to much at once.

[benoitf]

@skabashnyuk I think including EditorConfig as proposed by others should clearly help supporting not only Java as well as it can address some "classic PR comments" in the Pull Request like missing newline at the end of file, trim of spaces, indent for not only java files and is supported by a wide list of Editors.
This would really help on xml, Dockerfiles, typescript, JSON, etc.

[skabashnyuk]

I'm ok with your proposal. Can you do that as a separate issue?

Why separate?

Because one of the core parts is java only [3] https://github.com/google/google-java-format https://github.com/coveo/fmt-maven-plugin without them I think it's almost impossible to guarantee same results on different editors.

[benoitf]

it's a separate Pull Requests but I don't think it should be a fully separate issue as it's still under the same goal "Adopt tools to make contributions/reviews easier around Coding Style" (so more under the same "epic")

BTW EditorConfig is more global than Java. I mean, these are global rules (like indent, space triming) but there is nothing on order of imports (specific to java, etc)
So it's not trying to replace google format but it's an extra check for all other files.

[gazarenkov]

@benoitf we started to discuss it at least 4 months ago, you can check che-dev mail list, thread name is: "Che developers formatting rules for Java" (you took part and it was ended with practically the same resolution), then we discussed it in other places (like mattermost) and have several votes in this issue too. So, it definitely can be considered as "our decision".
I'd prefer "good enough" solution now (community really needs it) and not "presumably perfect" in several years.
Really appreciate @skabashnyuk who took responsibility for this dirty job.

[benoitf]

@gazarenkov well community should be still informed about steps that will follow a 4 months old discussion.

[benoitf]

thanks @skabashnyuk for the mail on che-dev

[sunix]

Thanks @skabashnyuk for the mail, I've created #5900 for dog fooding :)

[voievodin]

Make sure https://github.com/eclipse/che/wiki/Coding-Guidelines is removed

[skabashnyuk]

ok