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