[DISCUSS] Java code style
Locked
123
123
Re: [DISCUSS] Java code style
 
|
Re: [DISCUSS] Java code style
|
Re: [DISCUSS] Java code style
|
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
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 < > [hidden email]> 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 <[hidden email]> 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 <[hidden email]>: >>> >>>> 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 <[hidden email]> 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 < >>> [hidden email]> >>>> 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 <[hidden email]> >>> 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 <[hidden email]> >>>> 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 <[hidden email]>: >>>>>>>> >>>>>>>>> There ain’t no such thing as a free lunch and code style. >>>>>>>>> >>>>>>>>> On Thu, Oct 22, 2015 at 3:13 PM, Maximilian Michels < >>> [hidden email]> >>>>>>>>> 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 < >> [hidden email] >>>> >>>>>>>>> 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 <[hidden email]>: >>>>>>>>>>> >>>>>>>>>>>> Agreed. That's the reason why I am in favor of using vanilla >>>>>>>>> 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 < >>>>>>>> [hidden email]> >>>>>>>>>>>> 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 <[hidden email]> 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 < >>>>>>>>> [hidden email] >>>>>>>>>>> >>>>>>>>>>>>>>> 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 < >>>> [hidden email] >>>>>>>>> : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>>>>>> 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 < >>> [hidden email]> >>>>>>>>>> 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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> [2] >> https://google.github.io/styleguide/javaguide.html >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>> >>>> >>> >> > |
signature.asc (836 bytes)
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
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 <[hidden email]>: > >> 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 < >>> [hidden email]> 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 <[hidden email]> 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 <[hidden email]>: >>>>> >>>>>> 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 <[hidden email]> 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 < >>>>> [hidden email]> >>>>>> 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 <[hidden email]> >>>>> 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 <[hidden email]> >>>>>> 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 <[hidden email]>: >>>>>>>>>> >>>>>>>>>>> There ain’t no such thing as a free lunch and code style. >>>>>>>>>>> >>>>>>>>>>> On Thu, Oct 22, 2015 at 3:13 PM, Maximilian Michels < >>>>> [hidden email]> >>>>>>>>>>> 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 < >>>> [hidden email] >>>>>> >>>>>>>>>>> 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 <[hidden email]>: >>>>>>>>>>>>> >>>>>>>>>>>>>> Agreed. That's the reason why I am in favor of using vanilla >>>>>>>>>>> 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 < >>>>>>>>>> [hidden email]> >>>>>>>>>>>>>> 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 <[hidden email]> 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 < >>>>>>>>>>> [hidden email] >>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 < >>>>>> [hidden email] >>>>>>>>>>> : >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>>>>>>>> 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 < >>>>> [hidden email]> >>>>>>>>>>>> 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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [2] >>>> https://google.github.io/styleguide/javaguide.html >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> > |
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
Yes. I think that's a good compromise. Additionally, I vote for a
"deadline" (or "target date") to get those JIRAs done (even if we cannot enforce it) to not get "trapped" by the lazy approach. On 10/23/2015 02:12 PM, Fabian Hueske wrote: > 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 <[hidden email]>: > >> 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 <[hidden email]>: >>> >>>> 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 < >>>>> [hidden email]> 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 <[hidden email]> 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 <[hidden email]>: >>>>>>> >>>>>>>> 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 <[hidden email]> >> 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 < >>>>>>> [hidden email]> >>>>>>>> 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 <[hidden email]> >>>>>>> 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 < >> [hidden email]> >>>>>>>> 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 <[hidden email] >>> : >>>>>>>>>>>> >>>>>>>>>>>>> There ain’t no such thing as a free lunch and code style. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Oct 22, 2015 at 3:13 PM, Maximilian Michels < >>>>>>> [hidden email]> >>>>>>>>>>>>> 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 < >>>>>> [hidden email] >>>>>>>> >>>>>>>>>>>>> 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 <[hidden email] >>> : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Agreed. That's the reason why I am in favor of using vanilla >>>>>>>>>>>>> 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 < >>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>>>> 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 <[hidden email]> 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 < >>>>>>>>>>>>> [hidden email] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 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 < >>>>>>>> [hidden email] >>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>> [hidden email]> >>>>>>>>>>>>>> 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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> [2] >>>>>> https://google.github.io/styleguide/javaguide.html >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > |
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
Re: [DISCUSS] Java code style
|
|
| Free forum by Nabble | Edit this page |