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 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>> >>>> >>> >> >
signature.asc
Description: OpenPGP digital signature
