I like the idea to have a bit stricter code style which will increase code maintainability and makes it easier for people to go through the code. Furthermore, it will relieve us from code style comments while reviewing PRs which can be quite cumbersome.
Personally, I like the Google code style. Thus, +1 for both points. Just a remark: We should discuss the same for Flink's Scala style at some point. On Tue, Oct 20, 2015 at 2:54 PM, Márton Balassi <balassi.mar...@gmail.com> wrote: > +1 for both > > As we are planning to restructure the maven projects at the point that > breaks the PRs anyway, so going on step further at this point in time is > reasonable for me. > > On Tue, Oct 20, 2015 at 2:37 PM, Matthias J. Sax <mj...@apache.org> wrote: > > > big +1 for both! > > > > On 10/20/2015 02:31 PM, Ufuk Celebi 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 > > > > > > > >
