+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
