+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
>
>
>
