Which basically defaults back to lazily adding JavaDocs (with some bookkeeping).
I'd be +1 for that. 2015-10-23 14:09 GMT+02:00 Matthias J. Sax <mj...@apache.org>: > 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. > > > > 2015-10-23 13:13 GMT+02:00 Matthias J. Sax <mj...@apache.org>: > > > >> 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 for > >> 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 entire > >>> commit history? > >>> > >>> On Fri, Oct 23, 2015 at 11:51 AM, Vasiliki Kalavri < > >>> vasilikikala...@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 spaces, > >> but > >>>> it seems to me like an unnecessary change that would touch every > single > >>>> 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 <fhue...@gmail.com> 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 <u...@apache.org>: > >>>>> > >>>>>> I think that we have two open questions now: > >>>>>> > >>>>>> 1. Line length > >>>>>> > >>>>>> From the discussion so far, I think that no one wants 80 characters > >>>> 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’m not misrepresenting someone with the following summary of > >>>>>> positions. > >>>>>> > >>>>>> Tabs: > >>>>>> - Robert > >>>>>> - Max > >>>>>> - Fabian > >>>>>> (- Stephan) > >>>>>> > >>>>>> Spaces: > >>>>>> - Matthias > >>>>>> - Marton > >>>>>> - Till > >>>>>> - Gyula > >>>>>> - Henry > >>>>>> (- Stephan) > >>>>>> > >>>>>> Let’s wrap the discussion up by focusing on this question. > >>>>>> > >>>>>> What are the PROs/CONs for the respective approaches? If we went > with > >>>> the > >>>>>> opposing approach, would you voice a -1? E.g. would a “tabs person" > -1 > >>>> a > >>>>>> "spaces decision" and vice versa? > >>>>>> > >>>>>> – Ufuk > >>>>>> > >>>>>>> On 23 Oct 2015, at 10:34, 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 > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >> > > > >
