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