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 <[email protected]> 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
<[email protected]> wrote: > > > +1, it’s a hard work but meaningful. > > > > >
> | | > > lamberken > > IT > > | > > | > > ly.com > > [email protected] > > | >
> 签名由网易邮箱大师定制 > > > > > > On 11/19/2019 07:27，leesf<[email protected]> 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
<[email protected]> 于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 <[email protected]> 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 > > > > > > >
