To summarize up to this point: - All are in favour of Google check style (with the following possible exceptions) - Proposed exceptions so far: * Specific line length 100 vs. 120 characters * Keep tabs instead converting to spaces (this would translate to skipping/coming up with some indentation rules as well)
If we keep tabs, we will have to specify the line length relative to a tab size (like 4). Let’s keep the discussion going a little longer. I think it has proceeded in a very reasonable manner so far. Thanks for this! – Ufuk On Wed, Oct 21, 2015 at 10:29 AM, Fabian Hueske <fhue...@gmail.com> wrote: > Thanks Max for checking the modifications by the Google code style. > It is very good to know, that the impact on the code base would not be too > massive. If the Google code style would have touched almost every line, I > would have been in favor of converting to spaces. However, your assessment > is a strong argument to continue with tabs, IMO. > > Regarding the line length limit, I personally find 100 chars too narrow but > would be +1 for having a limit. > > +1 for discussing the Scala style in a separate thread. > > Fabian > > 2015-10-20 18:12 GMT+02:00 Maximilian Michels <m...@apache.org>: > > > 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 > > >> > > >
