You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hudi.apache.org by vino yang <ya...@gmail.com> on 2019/11/18 12:28:55 UTC
[DISCUSS] Introduce stricter comment and code style validation rules
Hi guys,
Currently, Hudi's comment and code styles do not have a uniform
specification on certain rules. I will list them below. With the rapid
development of the community, the inconsistent comment specification will
bring a lot of problems. I am here to assume that everyone is aware of its
importance, so I will not spend too much time emphasizing it.
In short, I want to add more detection rules to the current warehouse to
force everyone to follow a more "strict" code specification.
These rules are listed below:
1) All public classes must add class-level comments;
2) All comments must end with a clear "."
3) In the import statement of the class, clearly distinguish (by blank
lines) the import of Java SE and the import of non-java SE. Currently, I
saw at least two projects(Spark and Flink) that implement this rule. Flink
implements stricter rules than Spark. It is divided into several blocks
from top to bottom(owner import -> non-owner and non-JavaSE import -> Java
SE import -> static import), each block are sorted according to the natural
sequence of letters;
4) Reconfirm the method and whether the comment is consistency;
The first, second, and third points can be checked by setting the
check-style rule. The fourth point requires human confirmation.
Regarding the third point, everyone can express their views. According to
my personal experience, this strict model used by Flink also brings the
best reading experience. But this is a subjective feeling.
Additionally, I want to collect more ideas about this topic through this
thread and discuss the feasibility of them.
Any comments and feedback are commendable.
Best,
Vino
Re: Re: [DISCUSS] Introduce stricter comment and code style
validation rules
Posted by vino yang <ya...@gmail.com>.
Hi lamberken,
Reasonable. Will change the description of jira issue soon.
Best,
Vino
lamberken <la...@163.com> 于2019年11月21日周四 下午4:22写道：
> Hi, vino. I think we can set severity to info level, if so, use can check
> style themself.
>
>
>
>
>
>
> At 2019-11-21 15:43:34, "vino yang" <ya...@gmail.com> wrote:
> >Hi all,
> >
> >The umbrella issue[1] has been created, please feel free to join us to
> >improve the comment and code quality.
> >
> >Best,
> >Vino
> >
> >[1]: https://issues.apache.org/jira/browse/HUDI-354
> ><https://issues.apache.org/jira/browse/HUDI-354#>
> >
> >vino yang <ya...@gmail.com> 于2019年11月20日周三 下午7:33写道：
> >
> >>
> >> Hi guys,
> >>
> >> Since there is no objection. I will create an umbrella issue to track this
> >> work. The plan is:
> >>
> >> 1) Given relevant check style rules to find all the illegal points;
> >> 2) We will refactor modules one by one, each module mappings to one
> >> subtask;
> >> 3) Add global check style rule for the whole project
> >>
> >> Best,
> >> Vino
> >>
> >>
> >> On 11/20/2019 12:59, Y Ethan Guo <et...@gmail.com> wrote:
> >> +1 on all of the proposed rules. These will also make the javadoc more
> >> readable.
> >>
> >> On Mon, Nov 18, 2019 at 5:55 PM Vinoth Chandar <vi...@apache.org> wrote:
> >>
> >> > +1 on all three.
> >> >
> >> > Would there be a overhaul of existing code to add comments to all
> >> classes?
> >> > We are pretty reasonable already, but good to get this in shape.
> >> >
> >> > 17:54:37 [incubator-hudi]$ grep -R -B 1 "public class"
> >> hudi-*/src/main/java
> >> > | grep "public class" | wc -l
> >> > 274
> >> > 17:54:50 [incubator-hudi]$ grep -R -B 1 "public class"
> >> hudi-*/src/main/java
> >> > | grep "*/" | wc -l
> >> > 178
> >> > 17:55:06 [incubator-hudi]$
> >> >
> >> >
> >> >
> >> >
> >> > On Mon, Nov 18, 2019 at 5:48 PM lamberken <la...@163.com> wrote:
> >> >
> >> > > +1, it’s a hard work but meaningful.
> >> > >
> >> > >
> >> > > | |
> >> > > lamberken
> >> > > IT
> >> > > |
> >> > > |
> >> > > ly.com
> >> > > lamberken@163.com
> >> > > |
> >> > > 签名由网易邮箱大师定制
> >> > >
> >> > >
> >> > > On 11/19/2019 07:27，leesf<le...@gmail.com> wrote：
> >> > > Hi vino,
> >> > >
> >> > > Thanks for bringing ths discussion up.
> >> > > +1 on all. the third one seems a bit too strict and usually requires
> >> > manual
> >> > > processing of the import order, but I also agree and think it makes
> >> our
> >> > > project more professional. And I learned that the calcite community is
> >> > also
> >> > > applying this rule.
> >> > >
> >> > > Best,
> >> > > Leesf
> >> > >
> >> > >
> >> > > Pratyaksh Sharma <pr...@gmail.com> 于2019年11月18日周一 下午8:53写道：
> >> > >
> >> > > Having proper class level and method level comments always makes the
> >> life
> >> > > easier for any new user.
> >> > >
> >> > > +1 for points 1,2 and 4.
> >> > >
> >> > > On Mon, Nov 18, 2019 at 5:59 PM vino yang <ya...@gmail.com>
> >> wrote:
> >> > >
> >> > > Hi guys,
> >> > >
> >> > > Currently, Hudi's comment and code styles do not have a uniform
> >> > > specification on certain rules. I will list them below. With the rapid
> >> > > development of the community, the inconsistent comment specification
> >> will
> >> > > bring a lot of problems. I am here to assume that everyone is aware of
> >> > > its
> >> > > importance, so I will not spend too much time emphasizing it.
> >> > >
> >> > > In short, I want to add more detection rules to the current warehouse
> >> to
> >> > > force everyone to follow a more "strict" code specification.
> >> > >
> >> > > These rules are listed below:
> >> > >
> >> > > 1) All public classes must add class-level comments;
> >> > >
> >> > > 2) All comments must end with a clear "."
> >> > >
> >> > > 3) In the import statement of the class, clearly distinguish (by blank
> >> > > lines) the import of Java SE and the import of non-java SE. Currently,
> >> I
> >> > > saw at least two projects(Spark and Flink) that implement this rule.
> >> > > Flink
> >> > > implements stricter rules than Spark. It is divided into several
> >> blocks
> >> > > from top to bottom(owner import -> non-owner and non-JavaSE import ->
> >> > > Java
> >> > > SE import -> static import), each block are sorted according to the
> >> > > natural
> >> > > sequence of letters;
> >> > >
> >> > > 4) Reconfirm the method and whether the comment is consistency;
> >> > >
> >> > > The first, second, and third points can be checked by setting the
> >> > > check-style rule. The fourth point requires human confirmation.
> >> > >
> >> > > Regarding the third point, everyone can express their views. According
> >> to
> >> > > my personal experience, this strict model used by Flink also brings
> >> the
> >> > > best reading experience. But this is a subjective feeling.
> >> > >
> >> > > Additionally, I want to collect more ideas about this topic through
> >> this
> >> > > thread and discuss the feasibility of them.
> >> > >
> >> > > Any comments and feedback are commendable.
> >> > >
> >> > > Best,
> >> > > Vino
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >>
>
>
Re:Re: [DISCUSS] Introduce stricter comment and code style
validation rules
Posted by lamberken <la...@163.com>.
Hi, vino. I think we can set severity to info level, if so, use can check style themself.
At 2019-11-21 15:43:34, "vino yang" <ya...@gmail.com> wrote:
>Hi all,
>
>The umbrella issue[1] has been created, please feel free to join us to
>improve the comment and code quality.
>
>Best,
>Vino
>
>[1]: https://issues.apache.org/jira/browse/HUDI-354
><https://issues.apache.org/jira/browse/HUDI-354#>
>
>vino yang <ya...@gmail.com> 于2019年11月20日周三 下午7:33写道：
>
>>
>> Hi guys,
>>
>> Since there is no objection. I will create an umbrella issue to track this
>> work. The plan is:
>>
>> 1) Given relevant check style rules to find all the illegal points;
>> 2) We will refactor modules one by one, each module mappings to one
>> subtask;
>> 3) Add global check style rule for the whole project
>>
>> Best,
>> Vino
>>
>>
>> On 11/20/2019 12:59, Y Ethan Guo <et...@gmail.com> wrote:
>> +1 on all of the proposed rules. These will also make the javadoc more
>> readable.
>>
>> On Mon, Nov 18, 2019 at 5:55 PM Vinoth Chandar <vi...@apache.org> wrote:
>>
>> > +1 on all three.
>> >
>> > Would there be a overhaul of existing code to add comments to all
>> classes?
>> > We are pretty reasonable already, but good to get this in shape.
>> >
>> > 17:54:37 [incubator-hudi]$ grep -R -B 1 "public class"
>> hudi-*/src/main/java
>> > | grep "public class" | wc -l
>> > 274
>> > 17:54:50 [incubator-hudi]$ grep -R -B 1 "public class"
>> hudi-*/src/main/java
>> > | grep "*/" | wc -l
>> > 178
>> > 17:55:06 [incubator-hudi]$
>> >
>> >
>> >
>> >
>> > On Mon, Nov 18, 2019 at 5:48 PM lamberken <la...@163.com> wrote:
>> >
>> > > +1, it’s a hard work but meaningful.
>> > >
>> > >
>> > > | |
>> > > lamberken
>> > > IT
>> > > |
>> > > |
>> > > ly.com
>> > > lamberken@163.com
>> > > |
>> > > 签名由网易邮箱大师定制
>> > >
>> > >
>> > > On 11/19/2019 07:27，leesf<le...@gmail.com> wrote：
>> > > Hi vino,
>> > >
>> > > Thanks for bringing ths discussion up.
>> > > +1 on all. the third one seems a bit too strict and usually requires
>> > manual
>> > > processing of the import order, but I also agree and think it makes
>> our
>> > > project more professional. And I learned that the calcite community is
>> > also
>> > > applying this rule.
>> > >
>> > > Best,
>> > > Leesf
>> > >
>> > >
>> > > Pratyaksh Sharma <pr...@gmail.com> 于2019年11月18日周一 下午8:53写道：
>> > >
>> > > Having proper class level and method level comments always makes the
>> life
>> > > easier for any new user.
>> > >
>> > > +1 for points 1,2 and 4.
>> > >
>> > > On Mon, Nov 18, 2019 at 5:59 PM vino yang <ya...@gmail.com>
>> wrote:
>> > >
>> > > Hi guys,
>> > >
>> > > Currently, Hudi's comment and code styles do not have a uniform
>> > > specification on certain rules. I will list them below. With the rapid
>> > > development of the community, the inconsistent comment specification
>> will
>> > > bring a lot of problems. I am here to assume that everyone is aware of
>> > > its
>> > > importance, so I will not spend too much time emphasizing it.
>> > >
>> > > In short, I want to add more detection rules to the current warehouse
>> to
>> > > force everyone to follow a more "strict" code specification.
>> > >
>> > > These rules are listed below:
>> > >
>> > > 1) All public classes must add class-level comments;
>> > >
>> > > 2) All comments must end with a clear "."
>> > >
>> > > 3) In the import statement of the class, clearly distinguish (by blank
>> > > lines) the import of Java SE and the import of non-java SE. Currently,
>> I
>> > > saw at least two projects(Spark and Flink) that implement this rule.
>> > > Flink
>> > > implements stricter rules than Spark. It is divided into several
>> blocks
>> > > from top to bottom(owner import -> non-owner and non-JavaSE import ->
>> > > Java
>> > > SE import -> static import), each block are sorted according to the
>> > > natural
>> > > sequence of letters;
>> > >
>> > > 4) Reconfirm the method and whether the comment is consistency;
>> > >
>> > > The first, second, and third points can be checked by setting the
>> > > check-style rule. The fourth point requires human confirmation.
>> > >
>> > > Regarding the third point, everyone can express their views. According
>> to
>> > > my personal experience, this strict model used by Flink also brings
>> the
>> > > best reading experience. But this is a subjective feeling.
>> > >
>> > > Additionally, I want to collect more ideas about this topic through
>> this
>> > > thread and discuss the feasibility of them.
>> > >
>> > > Any comments and feedback are commendable.
>> > >
>> > > Best,
>> > > Vino
>> > >
>> > >
>> > >
>> >
>>
>>
Re: [DISCUSS] Introduce stricter comment and code style validation rules
Posted by vino yang <ya...@gmail.com>.
Hi all,
The umbrella issue[1] has been created, please feel free to join us to
improve the comment and code quality.
Best,
Vino
[1]: https://issues.apache.org/jira/browse/HUDI-354
<https://issues.apache.org/jira/browse/HUDI-354#>
vino yang <ya...@gmail.com> 于2019年11月20日周三 下午7:33写道：
>
> Hi guys,
>
> Since there is no objection. I will create an umbrella issue to track this
> work. The plan is:
>
> 1) Given relevant check style rules to find all the illegal points;
> 2) We will refactor modules one by one, each module mappings to one
> subtask;
> 3) Add global check style rule for the whole project
>
> Best,
> Vino
>
>
> On 11/20/2019 12:59, Y Ethan Guo <et...@gmail.com> wrote:
> +1 on all of the proposed rules. These will also make the javadoc more
> readable.
>
> On Mon, Nov 18, 2019 at 5:55 PM Vinoth Chandar <vi...@apache.org> wrote:
>
> > +1 on all three.
> >
> > Would there be a overhaul of existing code to add comments to all
> classes?
> > We are pretty reasonable already, but good to get this in shape.
> >
> > 17:54:37 [incubator-hudi]$ grep -R -B 1 "public class"
> hudi-*/src/main/java
> > | grep "public class" | wc -l
> > 274
> > 17:54:50 [incubator-hudi]$ grep -R -B 1 "public class"
> hudi-*/src/main/java
> > | grep "*/" | wc -l
> > 178
> > 17:55:06 [incubator-hudi]$
> >
> >
> >
> >
> > On Mon, Nov 18, 2019 at 5:48 PM lamberken <la...@163.com> wrote:
> >
> > > +1, it’s a hard work but meaningful.
> > >
> > >
> > > | |
> > > lamberken
> > > IT
> > > |
> > > |
> > > ly.com
> > > lamberken@163.com
> > > |
> > > 签名由网易邮箱大师定制
> > >
> > >
> > > On 11/19/2019 07:27，leesf<le...@gmail.com> wrote：
> > > Hi vino,
> > >
> > > Thanks for bringing ths discussion up.
> > > +1 on all. the third one seems a bit too strict and usually requires
> > manual
> > > processing of the import order, but I also agree and think it makes
> our
> > > project more professional. And I learned that the calcite community is
> > also
> > > applying this rule.
> > >
> > > Best,
> > > Leesf
> > >
> > >
> > > Pratyaksh Sharma <pr...@gmail.com> 于2019年11月18日周一 下午8:53写道：
> > >
> > > Having proper class level and method level comments always makes the
> life
> > > easier for any new user.
> > >
> > > +1 for points 1,2 and 4.
> > >
> > > On Mon, Nov 18, 2019 at 5:59 PM vino yang <ya...@gmail.com>
> wrote:
> > >
> > > Hi guys,
> > >
> > > Currently, Hudi's comment and code styles do not have a uniform
> > > specification on certain rules. I will list them below. With the rapid
> > > development of the community, the inconsistent comment specification
> will
> > > bring a lot of problems. I am here to assume that everyone is aware of
> > > its
> > > importance, so I will not spend too much time emphasizing it.
> > >
> > > In short, I want to add more detection rules to the current warehouse
> to
> > > force everyone to follow a more "strict" code specification.
> > >
> > > These rules are listed below:
> > >
> > > 1) All public classes must add class-level comments;
> > >
> > > 2) All comments must end with a clear "."
> > >
> > > 3) In the import statement of the class, clearly distinguish (by blank
> > > lines) the import of Java SE and the import of non-java SE. Currently,
> I
> > > saw at least two projects(Spark and Flink) that implement this rule.
> > > Flink
> > > implements stricter rules than Spark. It is divided into several
> blocks
> > > from top to bottom(owner import -> non-owner and non-JavaSE import ->
> > > Java
> > > SE import -> static import), each block are sorted according to the
> > > natural
> > > sequence of letters;
> > >
> > > 4) Reconfirm the method and whether the comment is consistency;
> > >
> > > The first, second, and third points can be checked by setting the
> > > check-style rule. The fourth point requires human confirmation.
> > >
> > > Regarding the third point, everyone can express their views. According
> to
> > > my personal experience, this strict model used by Flink also brings
> the
> > > best reading experience. But this is a subjective feeling.
> > >
> > > Additionally, I want to collect more ideas about this topic through
> this
> > > thread and discuss the feasibility of them.
> > >
> > > Any comments and feedback are commendable.
> > >
> > > Best,
> > > Vino
> > >
> > >
> > >
> >
>
>
Re: [DISCUSS] Introduce stricter comment and code style validation rules
Posted by vino yang <ya...@gmail.com>.
Hi guys, Since there is no objection. I will create an umbrella issue to track this work. The plan is: 1) Given relevant check style rules to find all the illegal points; 2) We will refactor modules one by one, each module mappings to one subtask; 3) Add global check style rule for the whole project Best, Vino On 11/20/2019 12:59, Y Ethan Guo wrote: +1 on all of the proposed rules. These will also make the javadoc more readable. On Mon, Nov 18, 2019 at 5:55 PM Vinoth Chandar <vi...@apache.org> wrote: > +1 on all three. > > Would there be a overhaul of existing code to add comments to all classes? > We are pretty reasonable already, but good to get this in shape. > > 17:54:37 [incubator-hudi]$ grep -R -B 1 "public class" hudi-*/src/main/java > | grep "public class" | wc -l > 274 > 17:54:50 [incubator-hudi]$ grep -R -B 1 "public class" hudi-*/src/main/java > | grep "*/" | wc -l > 178 > 17:55:06 [incubator-hudi]$ > > > > > On Mon, Nov 18, 2019 at 5:48 PM lamberken <la...@163.com> wrote: > > > +1, it’s a hard work but meaningful. > > > > > > | | > > lamberken > > IT > > | > > | > > ly.com > > lamberken@163.com > > | > > 签名由网易邮箱大师定制 > > > > > > On 11/19/2019 07:27，leesf<le...@gmail.com> wrote： > > Hi vino, > > > > Thanks for bringing ths discussion up. > > +1 on all. the third one seems a bit too strict and usually requires > manual > > processing of the import order, but I also agree and think it makes our > > project more professional. And I learned that the calcite community is > also > > applying this rule. > > > > Best, > > Leesf > > > > > > Pratyaksh Sharma <pr...@gmail.com> 于2019年11月18日周一 下午8:53写道： > > > > Having proper class level and method level comments always makes the life > > easier for any new user. > > > > +1 for points 1,2 and 4. > > > > On Mon, Nov 18, 2019 at 5:59 PM vino yang <ya...@gmail.com> wrote: > > > > Hi guys, > > > > Currently, Hudi's comment and code styles do not have a uniform > > specification on certain rules. I will list them below. With the rapid > > development of the community, the inconsistent comment specification will > > bring a lot of problems. I am here to assume that everyone is aware of > > its > > importance, so I will not spend too much time emphasizing it. > > > > In short, I want to add more detection rules to the current warehouse to > > force everyone to follow a more "strict" code specification. > > > > These rules are listed below: > > > > 1) All public classes must add class-level comments; > > > > 2) All comments must end with a clear "." > > > > 3) In the import statement of the class, clearly distinguish (by blank > > lines) the import of Java SE and the import of non-java SE. Currently, I > > saw at least two projects(Spark and Flink) that implement this rule. > > Flink > > implements stricter rules than Spark. It is divided into several blocks > > from top to bottom(owner import -> non-owner and non-JavaSE import -> > > Java > > SE import -> static import), each block are sorted according to the > > natural > > sequence of letters; > > > > 4) Reconfirm the method and whether the comment is consistency; > > > > The first, second, and third points can be checked by setting the > > check-style rule. The fourth point requires human confirmation. > > > > Regarding the third point, everyone can express their views. According to > > my personal experience, this strict model used by Flink also brings the > > best reading experience. But this is a subjective feeling. > > > > Additionally, I want to collect more ideas about this topic through this > > thread and discuss the feasibility of them. > > > > Any comments and feedback are commendable. > > > > Best, > > Vino > > > > > > >
Re: [DISCUSS] Introduce stricter comment and code style validation rules
Posted by Y Ethan Guo <et...@gmail.com>.
+1 on all of the proposed rules. These will also make the javadoc more
readable.
On Mon, Nov 18, 2019 at 5:55 PM Vinoth Chandar <vi...@apache.org> wrote:
> +1 on all three.
>
> Would there be a overhaul of existing code to add comments to all classes?
> We are pretty reasonable already, but good to get this in shape.
>
> 17:54:37 [incubator-hudi]$ grep -R -B 1 "public class" hudi-*/src/main/java
> | grep "public class" | wc -l
> 274
> 17:54:50 [incubator-hudi]$ grep -R -B 1 "public class" hudi-*/src/main/java
> | grep "*/" | wc -l
> 178
> 17:55:06 [incubator-hudi]$
>
>
>
>
> On Mon, Nov 18, 2019 at 5:48 PM lamberken <la...@163.com> wrote:
>
> > +1, it’s a hard work but meaningful.
> >
> >
> > | |
> > lamberken
> > IT
> > |
> > |
> > ly.com
> > lamberken@163.com
> > |
> > 签名由网易邮箱大师定制
> >
> >
> > On 11/19/2019 07:27，leesf<le...@gmail.com> wrote：
> > Hi vino,
> >
> > Thanks for bringing ths discussion up.
> > +1 on all. the third one seems a bit too strict and usually requires
> manual
> > processing of the import order, but I also agree and think it makes our
> > project more professional. And I learned that the calcite community is
> also
> > applying this rule.
> >
> > Best,
> > Leesf
> >
> >
> > Pratyaksh Sharma <pr...@gmail.com> 于2019年11月18日周一 下午8:53写道：
> >
> > Having proper class level and method level comments always makes the life
> > easier for any new user.
> >
> > +1 for points 1,2 and 4.
> >
> > On Mon, Nov 18, 2019 at 5:59 PM vino yang <ya...@gmail.com> wrote:
> >
> > Hi guys,
> >
> > Currently, Hudi's comment and code styles do not have a uniform
> > specification on certain rules. I will list them below. With the rapid
> > development of the community, the inconsistent comment specification will
> > bring a lot of problems. I am here to assume that everyone is aware of
> > its
> > importance, so I will not spend too much time emphasizing it.
> >
> > In short, I want to add more detection rules to the current warehouse to
> > force everyone to follow a more "strict" code specification.
> >
> > These rules are listed below:
> >
> > 1) All public classes must add class-level comments;
> >
> > 2) All comments must end with a clear "."
> >
> > 3) In the import statement of the class, clearly distinguish (by blank
> > lines) the import of Java SE and the import of non-java SE. Currently, I
> > saw at least two projects(Spark and Flink) that implement this rule.
> > Flink
> > implements stricter rules than Spark. It is divided into several blocks
> > from top to bottom(owner import -> non-owner and non-JavaSE import ->
> > Java
> > SE import -> static import), each block are sorted according to the
> > natural
> > sequence of letters;
> >
> > 4) Reconfirm the method and whether the comment is consistency;
> >
> > The first, second, and third points can be checked by setting the
> > check-style rule. The fourth point requires human confirmation.
> >
> > Regarding the third point, everyone can express their views. According to
> > my personal experience, this strict model used by Flink also brings the
> > best reading experience. But this is a subjective feeling.
> >
> > Additionally, I want to collect more ideas about this topic through this
> > thread and discuss the feasibility of them.
> >
> > Any comments and feedback are commendable.
> >
> > Best,
> > Vino
> >
> >
> >
>
Re: [DISCUSS] Introduce stricter comment and code style validation rules
Posted by Vinoth Chandar <vi...@apache.org>.
+1 on all three.
Would there be a overhaul of existing code to add comments to all classes?
We are pretty reasonable already, but good to get this in shape.
17:54:37 [incubator-hudi]$ grep -R -B 1 "public class" hudi-*/src/main/java
| grep "public class" | wc -l
274
17:54:50 [incubator-hudi]$ grep -R -B 1 "public class" hudi-*/src/main/java
| grep "*/" | wc -l
178
17:55:06 [incubator-hudi]$
On Mon, Nov 18, 2019 at 5:48 PM lamberken <la...@163.com> wrote:
> +1, it’s a hard work but meaningful.
>
>
> | |
> lamberken
> IT
> |
> |
> ly.com
> lamberken@163.com
> |
> 签名由网易邮箱大师定制
>
>
> On 11/19/2019 07:27，leesf<le...@gmail.com> wrote：
> Hi vino,
>
> Thanks for bringing ths discussion up.
> +1 on all. the third one seems a bit too strict and usually requires manual
> processing of the import order, but I also agree and think it makes our
> project more professional. And I learned that the calcite community is also
> applying this rule.
>
> Best,
> Leesf
>
>
> Pratyaksh Sharma <pr...@gmail.com> 于2019年11月18日周一 下午8:53写道：
>
> Having proper class level and method level comments always makes the life
> easier for any new user.
>
> +1 for points 1,2 and 4.
>
> On Mon, Nov 18, 2019 at 5:59 PM vino yang <ya...@gmail.com> wrote:
>
> Hi guys,
>
> Currently, Hudi's comment and code styles do not have a uniform
> specification on certain rules. I will list them below. With the rapid
> development of the community, the inconsistent comment specification will
> bring a lot of problems. I am here to assume that everyone is aware of
> its
> importance, so I will not spend too much time emphasizing it.
>
> In short, I want to add more detection rules to the current warehouse to
> force everyone to follow a more "strict" code specification.
>
> These rules are listed below:
>
> 1) All public classes must add class-level comments;
>
> 2) All comments must end with a clear "."
>
> 3) In the import statement of the class, clearly distinguish (by blank
> lines) the import of Java SE and the import of non-java SE. Currently, I
> saw at least two projects(Spark and Flink) that implement this rule.
> Flink
> implements stricter rules than Spark. It is divided into several blocks
> from top to bottom(owner import -> non-owner and non-JavaSE import ->
> Java
> SE import -> static import), each block are sorted according to the
> natural
> sequence of letters;
>
> 4) Reconfirm the method and whether the comment is consistency;
>
> The first, second, and third points can be checked by setting the
> check-style rule. The fourth point requires human confirmation.
>
> Regarding the third point, everyone can express their views. According to
> my personal experience, this strict model used by Flink also brings the
> best reading experience. But this is a subjective feeling.
>
> Additionally, I want to collect more ideas about this topic through this
> thread and discuss the feasibility of them.
>
> Any comments and feedback are commendable.
>
> Best,
> Vino
>
>
>
Re: [DISCUSS] Introduce stricter comment and code style validation
rules
Posted by lamberken <la...@163.com>.
+1, it’s a hard work but meaningful.
| |
lamberken
IT
|
|
ly.com
lamberken@163.com
|
签名由网易邮箱大师定制
On 11/19/2019 07:27，leesf<le...@gmail.com> wrote：
Hi vino,
Thanks for bringing ths discussion up.
+1 on all. the third one seems a bit too strict and usually requires manual
processing of the import order, but I also agree and think it makes our
project more professional. And I learned that the calcite community is also
applying this rule.
Best,
Leesf
Pratyaksh Sharma <pr...@gmail.com> 于2019年11月18日周一 下午8:53写道：
Having proper class level and method level comments always makes the life
easier for any new user.
+1 for points 1,2 and 4.
On Mon, Nov 18, 2019 at 5:59 PM vino yang <ya...@gmail.com> wrote:
Hi guys,
Currently, Hudi's comment and code styles do not have a uniform
specification on certain rules. I will list them below. With the rapid
development of the community, the inconsistent comment specification will
bring a lot of problems. I am here to assume that everyone is aware of
its
importance, so I will not spend too much time emphasizing it.
In short, I want to add more detection rules to the current warehouse to
force everyone to follow a more "strict" code specification.
These rules are listed below:
1) All public classes must add class-level comments;
2) All comments must end with a clear "."
3) In the import statement of the class, clearly distinguish (by blank
lines) the import of Java SE and the import of non-java SE. Currently, I
saw at least two projects(Spark and Flink) that implement this rule.
Flink
implements stricter rules than Spark. It is divided into several blocks
from top to bottom(owner import -> non-owner and non-JavaSE import ->
Java
SE import -> static import), each block are sorted according to the
natural
sequence of letters;
4) Reconfirm the method and whether the comment is consistency;
The first, second, and third points can be checked by setting the
check-style rule. The fourth point requires human confirmation.
Regarding the third point, everyone can express their views. According to
my personal experience, this strict model used by Flink also brings the
best reading experience. But this is a subjective feeling.
Additionally, I want to collect more ideas about this topic through this
thread and discuss the feasibility of them.
Any comments and feedback are commendable.
Best,
Vino
Re: [DISCUSS] Introduce stricter comment and code style validation rules
Posted by leesf <le...@gmail.com>.
Hi vino,
Thanks for bringing ths discussion up.
+1 on all. the third one seems a bit too strict and usually requires manual
processing of the import order, but I also agree and think it makes our
project more professional. And I learned that the calcite community is also
applying this rule.
Best,
Leesf
Pratyaksh Sharma <pr...@gmail.com> 于2019年11月18日周一 下午8:53写道：
> Having proper class level and method level comments always makes the life
> easier for any new user.
>
> +1 for points 1,2 and 4.
>
> On Mon, Nov 18, 2019 at 5:59 PM vino yang <ya...@gmail.com> wrote:
>
> > Hi guys,
> >
> > Currently, Hudi's comment and code styles do not have a uniform
> > specification on certain rules. I will list them below. With the rapid
> > development of the community, the inconsistent comment specification will
> > bring a lot of problems. I am here to assume that everyone is aware of
> its
> > importance, so I will not spend too much time emphasizing it.
> >
> > In short, I want to add more detection rules to the current warehouse to
> > force everyone to follow a more "strict" code specification.
> >
> > These rules are listed below:
> >
> > 1) All public classes must add class-level comments;
> >
> > 2) All comments must end with a clear "."
> >
> > 3) In the import statement of the class, clearly distinguish (by blank
> > lines) the import of Java SE and the import of non-java SE. Currently, I
> > saw at least two projects(Spark and Flink) that implement this rule.
> Flink
> > implements stricter rules than Spark. It is divided into several blocks
> > from top to bottom(owner import -> non-owner and non-JavaSE import ->
> Java
> > SE import -> static import), each block are sorted according to the
> natural
> > sequence of letters;
> >
> > 4) Reconfirm the method and whether the comment is consistency;
> >
> > The first, second, and third points can be checked by setting the
> > check-style rule. The fourth point requires human confirmation.
> >
> > Regarding the third point, everyone can express their views. According to
> > my personal experience, this strict model used by Flink also brings the
> > best reading experience. But this is a subjective feeling.
> >
> > Additionally, I want to collect more ideas about this topic through this
> > thread and discuss the feasibility of them.
> >
> > Any comments and feedback are commendable.
> >
> > Best,
> > Vino
> >
>
Re: [DISCUSS] Introduce stricter comment and code style validation rules
Posted by Pratyaksh Sharma <pr...@gmail.com>.
Having proper class level and method level comments always makes the life
easier for any new user.
+1 for points 1,2 and 4.
On Mon, Nov 18, 2019 at 5:59 PM vino yang <ya...@gmail.com> wrote:
> Hi guys,
>
> Currently, Hudi's comment and code styles do not have a uniform
> specification on certain rules. I will list them below. With the rapid
> development of the community, the inconsistent comment specification will
> bring a lot of problems. I am here to assume that everyone is aware of its
> importance, so I will not spend too much time emphasizing it.
>
> In short, I want to add more detection rules to the current warehouse to
> force everyone to follow a more "strict" code specification.
>
> These rules are listed below:
>
> 1) All public classes must add class-level comments;
>
> 2) All comments must end with a clear "."
>
> 3) In the import statement of the class, clearly distinguish (by blank
> lines) the import of Java SE and the import of non-java SE. Currently, I
> saw at least two projects(Spark and Flink) that implement this rule. Flink
> implements stricter rules than Spark. It is divided into several blocks
> from top to bottom(owner import -> non-owner and non-JavaSE import -> Java
> SE import -> static import), each block are sorted according to the natural
> sequence of letters;
>
> 4) Reconfirm the method and whether the comment is consistency;
>
> The first, second, and third points can be checked by setting the
> check-style rule. The fourth point requires human confirmation.
>
> Regarding the third point, everyone can express their views. According to
> my personal experience, this strict model used by Flink also brings the
> best reading experience. But this is a subjective feeling.
>
> Additionally, I want to collect more ideas about this topic through this
> thread and discuss the feasibility of them.
>
> Any comments and feedback are commendable.
>
> Best,
> Vino
>