You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Valentin Kulichenko <va...@gmail.com> on 2021/08/19 21:16:38 UTC
[DISCUSSION] Code style for Ignite 3
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
Re: [DISCUSSION] Code style for Ignite 3
Posted by Valentin Kulichenko <va...@gmail.com>.
Created tickets for the migration:
- https://issues.apache.org/jira/browse/IGNITE-15370
- https://issues.apache.org/jira/browse/IGNITE-15371
-Val
On Fri, Aug 20, 2021 at 7:23 AM Pavel Tupitsyn <pt...@apache.org> wrote:
> +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
> > <al...@gmail.com> wrote:
> > >
> > > +1
> > >
> > > пт, 20 авг. 2021 г. в 10:54, Alexander Polovtcev <
> > alexpolovtcev@gmail.com>:
> > >
> > > > Hi, Val. This is an extremely welcome change, thank you!
> > > >
> > > > On Fri, Aug 20, 2021 at 12:17 AM Valentin Kulichenko <
> > > > valentin.kulichenko@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
> >
>
Re: [DISCUSSION] Code style for Ignite 3
Posted by Pavel Tupitsyn <pt...@apache.org>.
+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
> <al...@gmail.com> wrote:
> >
> > +1
> >
> > пт, 20 авг. 2021 г. в 10:54, Alexander Polovtcev <
> alexpolovtcev@gmail.com>:
> >
> > > Hi, Val. This is an extremely welcome change, thank you!
> > >
> > > On Fri, Aug 20, 2021 at 12:17 AM Valentin Kulichenko <
> > > valentin.kulichenko@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
>
Re: [DISCUSSION] Code style for Ignite 3
Posted by Andrey Gura <ag...@apache.org>.
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
<al...@gmail.com> wrote:
>
> +1
>
> пт, 20 авг. 2021 г. в 10:54, Alexander Polovtcev <al...@gmail.com>:
>
> > Hi, Val. This is an extremely welcome change, thank you!
> >
> > On Fri, Aug 20, 2021 at 12:17 AM Valentin Kulichenko <
> > valentin.kulichenko@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
Re: [DISCUSSION] Code style for Ignite 3
Posted by Alexei Scherbakov <al...@gmail.com>.
+1
пт, 20 авг. 2021 г. в 10:54, Alexander Polovtcev <al...@gmail.com>:
> Hi, Val. This is an extremely welcome change, thank you!
>
> On Fri, Aug 20, 2021 at 12:17 AM Valentin Kulichenko <
> valentin.kulichenko@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
Re: [DISCUSSION] Code style for Ignite 3
Posted by Alexander Polovtcev <al...@gmail.com>.
Hi, Val. This is an extremely welcome change, thank you!
On Fri, Aug 20, 2021 at 12:17 AM Valentin Kulichenko <
valentin.kulichenko@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