+1, as long as 100% of the rules are checked automatically. On Fri, Aug 20, 2021 at 4:00 PM Andrey Gura <ag...@apache.org> wrote:
> 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 >
