I think that the line length limitation and the space indentation are the two rules which are most controversial in the Flink community because so far it has been done completely different. Thus, they would also inflict most of the changes. However, I think that at least the line length limitation (independent of the actual length to some extent) has a positive effect on readability of the code. Usually it's easier for people to find the next line if one doesn't have to do too much horizontal parsing.
I think it would be best to discuss the Scala style guide in a separate thread. Since there does not exist an exhaustive official style guide for Scala, it will require more work from our side to come up with one. On Tue, Oct 20, 2015 at 6:12 PM, Maximilian Michels <m...@apache.org> wrote: > I'm a little less excited about this. You might not be aware but, for > a large portion of the source code, we already follow the Google style > guide. The main changes will be tabs->spaces and 80/100 characters > line limit. > > Out of curiosity, I ran the official Google Style Checkstyle > configuration to confirm my suspicion: > > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml > The changes are very little if we turn off line length limit and > tabs-to-spaces conversion. > > There are some things I really like about the Google style, e.g. every > class has to have a JavaDoc and spaces after keywords (can't stand if > there aren't any). I'm not sure if we should change tabs to spaces, > because it means touching almost every single line of code. However, > if we keep the tabs, we cannot make use of the different indention for > case statements or wrapped lines...maybe that's a compromise we can > live with. > > If we introduce the Google Style for Java, will we also impose a > stricter style check for Scala? IMHO the line length is the strictest > part of the Scala Checkstyle. > > > On Tue, Oct 20, 2015 at 4:14 PM, Henry Saputra <henry.sapu...@gmail.com> > wrote: > > 1) yes. Been dancing this issue for a while. Let's pull the trigger. Did > > the exercise with Tachyon while back and did help readability and > > homogeneity of code. > > > > 2) +1 for Google Java style with documented exceptions and explanation on > > why. > > > > On Tuesday, October 20, 2015, Ufuk Celebi <u...@apache.org> wrote: > > > >> DISCLAIMER: This is not my personal idea, but a community discussion > from > >> some time ago. Don't kill the messenger. > >> > >> In March we were discussing issues with heterogeneity of the code [1]. > The > >> summary is that we had a consensus to enforce a stricter code style on > our > >> Java code base in order to make it easier to switch between projects > and to > >> have clear rules for new contributions. The main proposal in the last > >> discussion was to go with Google's Java code style. Not all were fully > >> satisfied with this, but still everyone agreed on some kind of style. > >> > >> I think the upcoming 0.10 release is a good point to finally go through > >> with these changes (right after the release/branch-off). > >> > >> I propose to go with Google's Java code style [2] as proposed earlier. > >> > >> PROs: > >> - Clear style guide available > >> - Tooling like checkstyle rules, IDE plugins already available > >> > >> CONs: > >> - Fully breaks our current style > >> > >> The main problem with this will be open pull requests, which will be > harder > >> to merge after all the changes. On the other hand, should pull requests > >> that have been open for a long time block this? Most of the important > >> changes will be merged for the release anyways. I think in the long run > we > >> will gain more than we loose by this (more homogenous code, clear > rules). > >> And it is questionable whether we will ever be able to do such a change > in > >> the future if we cannot do it now. The project will most likely grow and > >> attract more contributors, at which point it will be even harder to do. > >> > >> Please make sure to answer the following points in the discussion: > >> > >> 1) Are you (still) in favour of enforcing stricter rules on the Java > >> codebase? > >> > >> 2) If yes, would you be OK with the Google's Java code style? > >> > >> – Ufuk > >> > >> [1] > >> > >> > http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3ccanc1h_von0b5omnwzxchtyzwhakeghbzvquyk7s9o2a36b8...@mail.gmail.com%3e > >> > >> [2] https://google.github.io/styleguide/javaguide.html > >> >
