Return-Path: X-Original-To: apmail-flink-dev-archive@www.apache.org Delivered-To: apmail-flink-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5468618591 for ; Fri, 23 Oct 2015 12:10:15 +0000 (UTC) Received: (qmail 56814 invoked by uid 500); 23 Oct 2015 12:10:15 -0000 Delivered-To: apmail-flink-dev-archive@flink.apache.org Received: (qmail 56755 invoked by uid 500); 23 Oct 2015 12:10:15 -0000 Mailing-List: contact dev-help@flink.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flink.apache.org Delivered-To: mailing list dev@flink.apache.org Received: (qmail 56744 invoked by uid 99); 23 Oct 2015 12:10:15 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Oct 2015 12:10:15 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id AC856C5060 for ; Fri, 23 Oct 2015 12:10:14 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 1EVzu8WqFcse for ; Fri, 23 Oct 2015 12:10:03 +0000 (UTC) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 61C4B20634 for ; Fri, 23 Oct 2015 12:10:03 +0000 (UTC) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 54FC340048 for ; Fri, 23 Oct 2015 14:10:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id 3Gt22ttabOev for ; Fri, 23 Oct 2015 14:09:59 +0200 (CEST) Message-ID: <562A2377.90008@apache.org> Date: Fri, 23 Oct 2015 14:09:27 +0200 From: "Matthias J. Sax" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: dev@flink.apache.org Subject: Re: [DISCUSS] Java code style References: <56277775.4020009@apache.org> <8F4CCF5A-E8B7-44BA-AE78-59ACACE149F3@apache.org> <562A163D.1060103@apache.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tAlRueIF6V6bIJ0lBqT18lga8kUuVAHK8" --tAlRueIF6V6bIJ0lBqT18lga8kUuVAHK8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A "deadline" is not really forcible. However, if we have a JIRA for each module, we can enable JavaDoc enforcement when the JIRA is resolved. And we should discuss the progress about those tickets regularly (to hopefully find volunteers to resolve them) and use a special tag for them. On 10/23/2015 01:59 PM, Fabian Hueske wrote: > And who should be "forced" to write the docs before the deadline passes= ? > That's not going to work either, IMO. >=20 > 2015-10-23 13:13 GMT+02:00 Matthias J. Sax : >=20 >> I don't care about line length. >> >> Still prefer whitespaces because it gives aligned indention for line >> break in method calls (remember my example) But I would not vote -1 fo= r >> keeping tabs either. >> >> About JavaDocs: I agree with Max that lazy adding will not fix the >> problem. There should be some enforcement (maybe module by module over= >> time; backed up with JIRAs; and maybe a fixed date when the JavaDocs >> must be completed) >> >> -Matthias >> >> >> On 10/23/2015 11:55 AM, Stephan Ewen wrote: >>> I am with Vasia. >>> >>> Are spaces so important that we want to effectively wipe out the enti= re >>> commit history? >>> >>> On Fri, Oct 23, 2015 at 11:51 AM, Vasiliki Kalavri < >>> vasilikikalavri@gmail.com> wrote: >>> >>>> Hey, >>>> >>>> sorry I haven't replied so far. I was enjoying the thread tough :P >>>> >>>> I'm +1 for 120 line length and tabs. I wouldn't voice a -1 for space= s, >> but >>>> it seems to me like an unnecessary change that would touch every sin= gle >>>> Java file and without substantially improving anything. >>>> >>>> JavaDocs by-module with JIRAs to track progress seems like the best >> choice >>>> to me. >>>> >>>> -Vasia. >>>> >>>> On 23 October 2015 at 11:34, Fabian Hueske wrote= : >>>> >>>>> Enforcing JavaDocs (no, by-file, by-module, global) is another open= >>>>> question. >>>>> >>>>> Regarding the line length, I am OK with 120 chars. >>>>> >>>>> 2015-10-23 11:29 GMT+02:00 Ufuk Celebi : >>>>> >>>>>> I think that we have two open questions now: >>>>>> >>>>>> 1. Line length >>>>>> >>>>>> From the discussion so far, I think that no one wants 80 character= s >>>> line >>>>>> length. >>>>>> >>>>>> The final decision will be 100 vs. 120 characters. 120 characters = is >>>> what >>>>>> we have right now (for most parts), so it is fair to keep it that = way, >>>>> but >>>>>> enforce it (get rid of the longer lines). >>>>>> >>>>>> Is everyone OK with this? >>>>>> >>>>>> 2. Tabs vs. Spaces: >>>>>> >>>>>> I hope I=E2=80=99m not misrepresenting someone with the following = summary of >>>>>> positions. >>>>>> >>>>>> Tabs: >>>>>> - Robert >>>>>> - Max >>>>>> - Fabian >>>>>> (- Stephan) >>>>>> >>>>>> Spaces: >>>>>> - Matthias >>>>>> - Marton >>>>>> - Till >>>>>> - Gyula >>>>>> - Henry >>>>>> (- Stephan) >>>>>> >>>>>> Let=E2=80=99s wrap the discussion up by focusing on this question.= >>>>>> >>>>>> What are the PROs/CONs for the respective approaches? If we went w= ith >>>> the >>>>>> opposing approach, would you voice a -1? E.g. would a =E2=80=9Ctab= s person" -1 >>>> a >>>>>> "spaces decision" and vice versa? >>>>>> >>>>>> =E2=80=93 Ufuk >>>>>> >>>>>>> On 23 Oct 2015, at 10:34, Maximilian Michels wro= te: >>>>>>> >>>>>>> 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 g= oing >>>>>>> to happen that we lazily add comments because that's the reason w= hy >>>>>>> comments are missing in the first place... >>>>>>> >>>>>>> On Fri, Oct 23, 2015 at 12:05 AM, Henry Saputra < >>>>> henry.saputra@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 = >>>>> wrote: >>>>>>>>> I don't think a "let add comments to everything" effort gives u= s >>>> good >>>>>>>>> comments, actually. It just gives us checkmark comments that ma= ke >>>> the >>>>>> rules >>>>>>>>> pass. >>>>>>>>> >>>>>>>>> On Thu, Oct 22, 2015 at 3:29 PM, Fabian Hueske >>>>>> 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 : >>>>>>>>>> >>>>>>>>>>> There ain=E2=80=99t no such thing as a free lunch and code st= yle. >>>>>>>>>>> >>>>>>>>>>> On Thu, Oct 22, 2015 at 3:13 PM, Maximilian Michels < >>>>> mxm@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 < >>>> fhueske@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 st= art >>>> a >>>>>>>>>>> serious >>>>>>>>>>>>> effort to add the missing docs? >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-10-21 13:31 GMT+02:00 Matthias J. Sax : >>>>>>>>>>>>> >>>>>>>>>>>>>> Agreed. That's the reason why I am in favor of using vanil= la >>>>>> Google >>>>>>>>>>> code >>>>>>>>>>>>>> style. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/21/2015 12:31 PM, Stephan Ewen wrote: >>>>>>>>>>>>>>> We started out originally with mixed tab/spaces, but it e= nded >>>>> 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=C3=B3ra < >>>>>>>>>> gyula.fora@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 ezt =C3=ADrta (id=C5=91= 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= =2E >>>> 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 re= sult >>>>> 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 len= gth >>>>>>>>>>> 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 leng= th >>>>>>>>>> relative >>>>>>>>>>>> to a >>>>>>>>>>>>>>>>> tab >>>>>>>>>>>>>>>>>> size (like 4). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Let=E2=80=99s keep the discussion going a little longe= r. I think >>>> it >>>>>> has >>>>>>>>>>>>>>>> proceeded >>>>>>>>>>>>>>>>>> in a very reasonable manner so far. Thanks for this! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> =E2=80=93 Ufuk >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Oct 21, 2015 at 10:29 AM, Fabian Hueske < >>>>>>>>>>> fhueske@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks Max for checking the modifications by the Goog= le >>>>> 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 10= 0 >>>>> chars >>>>>>>>>> too >>>>>>>>>>>>>>>> narrow >>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>> would be +1 for having a limit. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> +1 for discussing the Scala style in a separate threa= d. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Fabian >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2015-10-20 18:12 GMT+02:00 Maximilian Michels < >>>>>> mxm@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 follo= w >>>> 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/resource= s/google_checks.xml >>>>>>>>>>>>>>>>>>>> The changes are very little if we turn off line leng= th >>>>> 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 keyword= s >>>>> (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 o= f >>>>> code. >>>>>>>>>>>> However, >>>>>>>>>>>>>>>>>>>> if we keep the tabs, we cannot make use of the diffe= rent >>>>>>>>>>>> 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 a= lso >>>>>>>>>> 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.saputra@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 excepti= ons >>>>> and >>>>>>>>>>>>>>>> explanation >>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>> why. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Tuesday, October 20, 2015, Ufuk Celebi < >>>>> uce@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 heterogene= ity >>>> 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 switc= h >>>>>> 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= =2E >>>> 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 alrea= dy >>>>>>>>>>> available >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> CONs: >>>>>>>>>>>>>>>>>>>>>> - Fully breaks our current style >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The main problem with this will be open pull reque= sts, >>>>>>>>>> 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? Mo= st >>>> 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 homogen= ous >>>>>> code, >>>>>>>>>>>> clear >>>>>>>>>>>>>>>>>>>> rules). >>>>>>>>>>>>>>>>>>>>>> And it is questionable whether we will ever be abl= e to >>>>> do >>>>>>>>>>> such >>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>> change >>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>> the future if we cannot do it now. The project wil= l >>>> 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? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> =E2=80=93 Ufuk >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>> >>>>> >>>> >> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC= 1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [2] >>>> https://google.github.io/styleguide/javaguide.html >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> >=20 --tAlRueIF6V6bIJ0lBqT18lga8kUuVAHK8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWKiN9AAoJEFCVK48prEZ4fAcQAMjKymkkpy0X/qzP8kG1Bths YCKcwC0sCDf7eV+x8xyxPlTInZ2DpTlNzGG6lTakUJrNrkJmajuw894FVrUUcvab RtTCN0xN5Czx/iE0fmvzi58gm8G66ixtRLoicuNlQz65qnTfj2weItGOKqB6gcEm L7GZKdegjtQn1UNiZ7R05cM5n6vYNAD1njFDtmali9koH2BBzIn7JfnnebNw5mAa 3X9VCn3VbCMmb0nqTQ6OPjc98Sz6IDx0nr2qHdNj6VZywI4ktGRoauX12p0YDKoj qaSP/mA4SaWbPGEfJYa4ftgLXojPEHXY0tb4IUnVMRmj6OY0H+tzTrjrEpgfH3ax bsw+cllJtGZElpVogKcToP8Vej9nGBqOGjbZgeeSVvMDerTEju/KSQQriAxlbEdT L6GsEpNSwiEZsSQgtzGny4ao48/yOF0vljIMB0Gbs6c4nWsgHSaoFeNfTXd15VOc FHhnW87Tgf6jaKERyrAKDNxqtsw5wJGUibskaYiv5QWYALiqQAod4fjeenJRfDVz 8PuISBQra0S+QL5ly7J/pjBORIudRG7pfH/G/ThWmn99cRVpSpfXCk9u2+8zpmUj MQS0X82KIB6esplVyevxm141/7XZz3CqrN769zHqoj2UFvT5vhAXcbUug62TeMtd W7orOnSrwOWwVRdzV+gA =Gpf3 -----END PGP SIGNATURE----- --tAlRueIF6V6bIJ0lBqT18lga8kUuVAHK8--