Minor thing in favour of spaces: Reviewability on GitHub is improved (they use 8 spaces for tabs and line length of 120, which often results in too long lines).
> On 09 Nov 2015, at 13:53, Fabian Hueske <fhue...@gmail.com> wrote: > > I don't see other benefits except maybe being closer to the vanilla Google > style. > > 2015-11-02 20:46 GMT+01:00 Stephan Ewen <se...@apache.org>: > >> 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 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >>> >>
