Looks good to me. But Idea configuration for style check is not enough. It helps developers but does not automate style checking.
Checkstyle project provides ready to use config based on Google Code Style [1]. I hope it matches well with Idea config and we'll avoid any confusing incidents. Let's start with this convention and adopt it to our needs if needed. [1] https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml On Fri, Aug 20, 2021 at 12:02 PM Alexei Scherbakov <alexey.scherbak...@gmail.com> wrote: > > +1 > > пт, 20 авг. 2021 г. в 10:54, Alexander Polovtcev <alexpolovt...@gmail.com>: > > > Hi, Val. This is an extremely welcome change, thank you! > > > > On Fri, Aug 20, 2021 at 12:17 AM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Igniters, > > > > > > I would like to discuss a potential change to the coding guidelines for > > > Ignite 3. Currently, we're using the existing guidelines inherited from > > > Ignite 2, which are described here: > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines > > > > > > Current guidelines, however, exist for many years and have several > > issues. > > > They are cumbersome, carry a lot of legacy stuff, and can't be automated. > > > Every now and then, they seem to cause questions and confusion. > > > > > > While it's hard to make drastic changes in Ignite 2, we still have a > > great > > > opportunity to update the guidelines in Ignite 3. I would identify two > > > major goals here: > > > > > > 1. Simplification. Having too many rules and restrictions tend to > > > complicate development rather than providing any value. We should come > > > up > > > with a minimum set of rules and then make amends one by one if needed. > > > 2. The ability for automation. I hold a strong belief that code style > > > checking has to become a part of the build. Therefore, we need to make > > > sure > > > that any rule that ends up in the guideline can be automatically > > > verified. > > > > > > I propose the following process to define the new guideline: > > > > > > 1. Use Google code style as the starting point: > > > https://google.github.io/styleguide/javaguide.html > > > 2. Replace the 100 column limit with 140. The latter is the value we > > > already use in Ignite 2, and it seems to be more reasonable, in my > > > opinion. > > > 3. Use 4 spaces block indentation and 8 spaces for continuation (as > > > opposed to 2 and 4). Nothing wrong with 2 spaces, in my view, but 4 > > > spaces > > > should provide a smoother transition, as we're really used to this > > > style. > > > 4. For any other changes, initiate separate discussions going forward. > > > > > > Several reasons why I specifically propose Google style: > > > > > > 1. This is essentially the standard for many projects. I don't think > > > there is a need for us to reinvent the wheel. > > > 2. It's minimalistic and developer-friendly. No overcomplication. > > > 3. (probably the most important) It comes with all the required tools > > > and configurations for automation (e.g., here is the config for IDEA: > > > > > https://github.com/google/error-prone/blob/master/.idea/GoogleStyle.xml > > > ) > > > > > > Please let me know what you think. If there are no objections, I will > > start > > > the process. > > > > > > -Val > > > > > > > > > -- > > With regards, > > Aleksandr Polovtcev > > > > > -- > > Best regards, > Alexei Scherbakov
