I think by now virtually everyone prefers spaces if it came for free, so it is a matter of making an educated decision about the cost/benefit tradeoffs.
What are the benefits of spaces in the style other than people liking the looks of space-formatted code better (aesthetics, schmaesthetics ;-) ) On Mon, Nov 2, 2015 at 5:38 AM, Matthias J. Sax <mj...@apache.org> wrote: > Thanks for the summary Fabian. > > Maybe we should have kind of a vote about this. No classical Apache vote > though, but voting for different options (so only +1), and the option > with the highest score wins? (Not sure if this is possible to do...) > > About spaced vs. tabs: > > "AFAIR, nobody said to have a personal preferences of tabs over spaces." > > I think this is wrong. If I am correct, Till and myself would prefer > spaces (but non of us is super strict about this -- we could both live > with tabs too). > > -Matthias > > On 11/02/2015 12:14 PM, Fabian Hueske wrote: > > OK, I'll try to summarize the discussion so far (please correct me if I > got > > something wrong): > > > > Everybody is in favor of adding a stricter code style based on the Google > > Java code style. > > Main points of discussion are: > > 1) Line length > > 2) JavaDocs > > 3) Tabs vs. Spaces > > > > -- Line length > > Issue: > > Google code style demands 80 or 100 chars line length limit. > > Some people find this too narrow. > > > > Discussion so far: > > Nobody objected against a limit of 120 chars, AFAIR. > > > > -- JavaDocs > > Issue: > > Google code style says "At the *minimum*, Javadoc is present for every > > public class, and every public or protected member of such a class, with > a > > few exceptions noted below." Exceptions are self-explanatory methods like > > getters and setters and overwritten method. > > Significant parts of the Flink code base do not comply with this > > requirement. It would be a huge effort to add the corresponding code > > documentation. > > > > Discussion so far: > > Disable JavaDoc checks when adding the code style and opening JIRAs for > > adding JavaDocs on a per Maven module level (with potentially subissues) > > with target dates. Once a module complies to the rule, the JavaDoc check > is > > enabled in the checkstyle. > > > > -- Tabs vs. Spaces > > Issue: > > The Google code style requires two spaces for indention. The Java code > base > > of Flink uses tabs. Moving from tabs to spaces would touch every line of > > Java code and therefore might make the tracking of changes in the past > much > > harder. > > Max provided some numbers for applying the Google code style on the > current > > code base: The style checker found 28k violations (possibly multiple ones > > per LOC) on 121k LOC of Java code in 1601 out of 3251 Java classes. So > > Google code style without spaces would touch every second file and about > > every 4th line of code. The question I have, would it be easier to track > > history with a commit that touches 1/2 (or 1/4) of the code base compared > > to one that touches everything. > > > > Discussion so far: > > AFAIR, nobody said to have a personal preferences of tabs over spaces. > > However, some people raised concerns that the implied changes of moving > the > > code base from tabs to spaces would be too massive and the "benefits" > would > > not justify the "cost" of the change. > > I think, this is the main point of discussion, right now. > > > > If we want to come to a conclusion, we should not let this discussion > fall > > asleep (as happened a few times in the past). > > > > Does anybody NOT agree with the "solutions" for line length and JavaDocs, > > i.e., 120 chars and "lazy" adding of JavaDocs with JIRA tracking, or has > > another proposal? > > How can we resolve the Tabs vs. Spaces discussion? > > > > Cheers, Fabian > > > > > > > > 2015-10-30 18:16 GMT+01:00 Maximilian Michels <m...@apache.org>: > > > >> I looked up if the Checkstyle plugin would also support tabs with a > >> fixed line length. Indeed, this is possible because a tab can be > >> mapped to a fixed number of spaces. > >> > >> I've modified the default Google Style Checkstyle file. I changed the > >> indention to tabs (2 spaces) and increased the line length to 120: > >> https://gist.github.com/mxm/2ca4ef7702667c167d10 > >> > >> The scan of the entire Flink project resulted in 27,992 items in 1601 > >> files. This is roughly corresponds to the number of lines we would > >> have to touch to comply with the style rules. Note that, one line may > >> contain multiple items. A lot of the items are import statements. > >> > >> Next, I tried running the vanilla Google Style Checkstyle file over > >> the entire code base but my IntelliJ crashed. Using Maven, I wasn't > >> able to get a total result displayed but I'm assuming it would be > >> almost all lines of Flink code that had a violation due to tabs. > >> > >> On Mon, Oct 26, 2015 at 6:56 PM, Suneel Marthi <suneel.mar...@gmail.com > > > >> wrote: > >>> 2 spaces is the convention that's followed on Mahout and Oryx. > >>> > >>> On Mon, Oct 26, 2015 at 1:42 PM, Till Rohrmann <trohrm...@apache.org> > >> wrote: > >>> > >>>> Concerning question 2 Tabs vs. Spaces, in case of spaces we would have > >> to > >>>> decide on the number of spaces, too. The Google Java style says to use > >> a 2 > >>>> space indentation, which is in my opinion sufficient to distinguish > >>>> different indentations levels from each other. Furthermore, it would > >> save > >>>> some space. > >>>> > >>>> I would not vote -1 if we keep tabs. > >>>> > >>>> > >>>> > >>>> On Sat, Oct 24, 2015 at 8:33 PM, Henry Saputra < > henry.sapu...@gmail.com > >>> > >>>> wrote: > >>>> > >>>>> +1 for adding restriction for Javadoc at least at the header of > public > >>>>> classes and methods. > >>>>> > >>>>> We did the exercise in Twill and seemed to work pretty well. > >>>>> > >>>>> On Fri, Oct 23, 2015 at 1:34 AM, Maximilian Michels <m...@apache.org> > >>>>> wrote: > >>>>>> I don't think lazily adding comments will work. However, I'm fine > >> with > >>>>>> adding all the checkstyle rules one module at a time (with a jira > >>>>>> issue to keep track of the modules already converted). It's not > >> going > >>>>>> to happen that we lazily add comments because that's the reason why > >>>>>> comments are missing in the first place... > >>>>>> > >>>>>> On Fri, Oct 23, 2015 at 12:05 AM, Henry Saputra < > >>>> henry.sapu...@gmail.com> > >>>>> wrote: > >>>>>>> Could we make certain rules to give warning instead of error? > >>>>>>> > >>>>>>> This would allow us to cherry-pick certain rules we would like > >> people > >>>>>>> to follow but not strictly enforced. > >>>>>>> > >>>>>>> - Henry > >>>>>>> > >>>>>>> On Thu, Oct 22, 2015 at 9:20 AM, Stephan Ewen <se...@apache.org> > >>>> wrote: > >>>>>>>> I don't think a "let add comments to everything" effort gives us > >> good > >>>>>>>> comments, actually. It just gives us checkmark comments that make > >> the > >>>>> rules > >>>>>>>> pass. > >>>>>>>> > >>>>>>>> On Thu, Oct 22, 2015 at 3:29 PM, Fabian Hueske <fhue...@gmail.com > >>> > >>>>> wrote: > >>>>>>>> > >>>>>>>>> Sure, I don't expect it to be free. > >>>>>>>>> But everybody should be aware of the cost of adding this code > >> style, > >>>>> i.e., > >>>>>>>>> spending a huge amount of time on reformatting and documenting > >> code. > >>>>>>>>> > >>>>>>>>> Alternatively, we could drop the JavaDocs rule and make the > >>>> transition > >>>>>>>>> significantly cheaper. > >>>>>>>>> > >>>>>>>>> 2015-10-22 15:24 GMT+02:00 Till Rohrmann <trohrm...@apache.org>: > >>>>>>>>> > >>>>>>>>>> There ain’t no such thing as a free lunch and code style. > >>>>>>>>>> > >>>>>>>>>> On Thu, Oct 22, 2015 at 3:13 PM, Maximilian Michels < > >>>> m...@apache.org > >>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> I think we have to document all these classes. Code Style > >>>> doesn't > >>>>> come > >>>>>>>>>>> for free :) > >>>>>>>>>>> > >>>>>>>>>>> On Thu, Oct 22, 2015 at 3:09 PM, Fabian Hueske < > >>>> fhue...@gmail.com > >>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>>>> Any ideas how to deal with the mandatory JavaDoc rule for > >>>>> existing > >>>>>>>>>> code? > >>>>>>>>>>>> Just adding empty headers to make the checkstyle pass or > >>>> start a > >>>>>>>>>> serious > >>>>>>>>>>>> effort to add the missing docs? > >>>>>>>>>>>> > >>>>>>>>>>>> 2015-10-21 13:31 GMT+02:00 Matthias J. Sax < > >> mj...@apache.org > >>>>> : > >>>>>>>>>>>> > >>>>>>>>>>>>> Agreed. That's the reason why I am in favor of using > >> vanilla > >>>>> Google > >>>>>>>>>> code > >>>>>>>>>>>>> style. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 10/21/2015 12:31 PM, Stephan Ewen wrote: > >>>>>>>>>>>>>> We started out originally with mixed tab/spaces, but it > >>>>> ended up > >>>>>>>>>> with > >>>>>>>>>>>>>> people mixing spaces and tabs arbitrarily, and there is > >>>>> little way > >>>>>>>>>> to > >>>>>>>>>>>>>> enforce Matthias' specific suggestion via checkstyle. > >>>>>>>>>>>>>> That's why we dropped spaces alltogether... > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Wed, Oct 21, 2015 at 12:03 PM, Gyula Fóra < > >>>>>>>>> gyula.f...@gmail.com> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I think the nice thing about a common codestyle is that > >>>>> everyone > >>>>>>>>>> can > >>>>>>>>>>> set > >>>>>>>>>>>>>>> the template in the IDE and use the formatting > >> commands. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Matthias's suggestion makes this practically > >> impossible so > >>>>> -1 for > >>>>>>>>>>> mixed > >>>>>>>>>>>>>>> tabs/spaces from my side. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Matthias J. Sax <mj...@apache.org> ezt írta (időpont: > >>>>> 2015. okt. > >>>>>>>>>>> 21., > >>>>>>>>>>>>> Sze, > >>>>>>>>>>>>>>> 11:46): > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I actually like tabs a lot, however, in a "mixed" > >> style > >>>>> together > >>>>>>>>>>> with > >>>>>>>>>>>>>>>> spaces. Example: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> myVar.callMethod(param1, // many more > >>>>>>>>>>>>>>>> .................paramX); // the dots mark > >> space > >>>>>>>>> indention > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> indenting "paramX" with tabs does not give nice > >> aliment. > >>>>> Not > >>>>>>>>> sure > >>>>>>>>>> if > >>>>>>>>>>>>>>>> this would be a feasible compromise to keeps tabs in > >>>>> general, > >>>>>>>>> but > >>>>>>>>>>> use > >>>>>>>>>>>>>>>> space for cases as above. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> If this in no feasible compromise, I would prefer > >> space > >>>> to > >>>>> get > >>>>>>>>> the > >>>>>>>>>>>>>>>> correct indention in examples as above. Even if this > >>>>> result in a > >>>>>>>>>>>>>>>> complete reformatting of the whole code. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Why this? Everybody can set this in it's IDE/editor as > >>>>> he/she > >>>>>>>>>>> wishes... > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> If we keep tabs, we will have to specify the line > >>>> length > >>>>>>>>>> relative > >>>>>>>>>>> to > >>>>>>>>>>>>> a > >>>>>>>>>>>>>>>> tab > >>>>>>>>>>>>>>>>>> size (like 4). > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -Matthias > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 10/21/2015 11:06 AM, Ufuk Celebi wrote: > >>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>> > >>>> > >> > > > >
