I wouldn't stop with GitHub - the main benefit for spaces is that the code looks the same on all viewers because it does not depend on a user-specific parameter (the size of the tab).
2015-11-09 14:02 GMT+01:00 Ufuk Celebi <u...@apache.org>: > Minor thing in favour of spaces: Reviewability on GitHub is improved (they > use 8 spaces for tabs and line length of 120, which often results in too > long lines). > > > On 09 Nov 2015, at 13:53, Fabian Hueske <fhue...@gmail.com> wrote: > > > > I don't see other benefits except maybe being closer to the vanilla > Google > > style. > > > > 2015-11-02 20:46 GMT+01:00 Stephan Ewen <se...@apache.org>: > > > >> I think by now virtually everyone prefers spaces if it came for free, > so it > >> is a matter of making an educated decision about the cost/benefit > >> tradeoffs. > >> > >> What are the benefits of spaces in the style other than people liking > the > >> looks of space-formatted code better (aesthetics, schmaesthetics ;-) ) > >> > >> > >> On Mon, Nov 2, 2015 at 5:38 AM, Matthias J. Sax <mj...@apache.org> > wrote: > >> > >>> Thanks for the summary Fabian. > >>> > >>> Maybe we should have kind of a vote about this. No classical Apache > vote > >>> though, but voting for different options (so only +1), and the option > >>> with the highest score wins? (Not sure if this is possible to do...) > >>> > >>> About spaced vs. tabs: > >>>> "AFAIR, nobody said to have a personal preferences of tabs over > >> spaces." > >>> > >>> I think this is wrong. If I am correct, Till and myself would prefer > >>> spaces (but non of us is super strict about this -- we could both live > >>> with tabs too). > >>> > >>> -Matthias > >>> > >>> On 11/02/2015 12:14 PM, Fabian Hueske wrote: > >>>> OK, I'll try to summarize the discussion so far (please correct me if > I > >>> got > >>>> something wrong): > >>>> > >>>> Everybody is in favor of adding a stricter code style based on the > >> Google > >>>> Java code style. > >>>> Main points of discussion are: > >>>> 1) Line length > >>>> 2) JavaDocs > >>>> 3) Tabs vs. Spaces > >>>> > >>>> -- Line length > >>>> Issue: > >>>> Google code style demands 80 or 100 chars line length limit. > >>>> Some people find this too narrow. > >>>> > >>>> Discussion so far: > >>>> Nobody objected against a limit of 120 chars, AFAIR. > >>>> > >>>> -- JavaDocs > >>>> Issue: > >>>> Google code style says "At the *minimum*, Javadoc is present for every > >>>> public class, and every public or protected member of such a class, > >> with > >>> a > >>>> few exceptions noted below." Exceptions are self-explanatory methods > >> like > >>>> getters and setters and overwritten method. > >>>> Significant parts of the Flink code base do not comply with this > >>>> requirement. It would be a huge effort to add the corresponding code > >>>> documentation. > >>>> > >>>> Discussion so far: > >>>> Disable JavaDoc checks when adding the code style and opening JIRAs > for > >>>> adding JavaDocs on a per Maven module level (with potentially > >> subissues) > >>>> with target dates. Once a module complies to the rule, the JavaDoc > >> check > >>> is > >>>> enabled in the checkstyle. > >>>> > >>>> -- Tabs vs. Spaces > >>>> Issue: > >>>> The Google code style requires two spaces for indention. The Java code > >>> base > >>>> of Flink uses tabs. Moving from tabs to spaces would touch every line > >> of > >>>> Java code and therefore might make the tracking of changes in the past > >>> much > >>>> harder. > >>>> Max provided some numbers for applying the Google code style on the > >>> current > >>>> code base: The style checker found 28k violations (possibly multiple > >> ones > >>>> per LOC) on 121k LOC of Java code in 1601 out of 3251 Java classes. So > >>>> Google code style without spaces would touch every second file and > >> about > >>>> every 4th line of code. The question I have, would it be easier to > >> track > >>>> history with a commit that touches 1/2 (or 1/4) of the code base > >> compared > >>>> to one that touches everything. > >>>> > >>>> Discussion so far: > >>>> AFAIR, nobody said to have a personal preferences of tabs over spaces. > >>>> However, some people raised concerns that the implied changes of > moving > >>> the > >>>> code base from tabs to spaces would be too massive and the "benefits" > >>> would > >>>> not justify the "cost" of the change. > >>>> I think, this is the main point of discussion, right now. > >>>> > >>>> If we want to come to a conclusion, we should not let this discussion > >>> fall > >>>> asleep (as happened a few times in the past). > >>>> > >>>> Does anybody NOT agree with the "solutions" for line length and > >> JavaDocs, > >>>> i.e., 120 chars and "lazy" adding of JavaDocs with JIRA tracking, or > >> has > >>>> another proposal? > >>>> How can we resolve the Tabs vs. Spaces discussion? > >>>> > >>>> Cheers, Fabian > >>>> > >>>> > >>>> > >>>> 2015-10-30 18:16 GMT+01:00 Maximilian Michels <m...@apache.org>: > >>>> > >>>>> I looked up if the Checkstyle plugin would also support tabs with a > >>>>> fixed line length. Indeed, this is possible because a tab can be > >>>>> mapped to a fixed number of spaces. > >>>>> > >>>>> I've modified the default Google Style Checkstyle file. I changed the > >>>>> indention to tabs (2 spaces) and increased the line length to 120: > >>>>> https://gist.github.com/mxm/2ca4ef7702667c167d10 > >>>>> > >>>>> The scan of the entire Flink project resulted in 27,992 items in 1601 > >>>>> files. This is roughly corresponds to the number of lines we would > >>>>> have to touch to comply with the style rules. Note that, one line may > >>>>> contain multiple items. A lot of the items are import statements. > >>>>> > >>>>> Next, I tried running the vanilla Google Style Checkstyle file over > >>>>> the entire code base but my IntelliJ crashed. Using Maven, I wasn't > >>>>> able to get a total result displayed but I'm assuming it would be > >>>>> almost all lines of Flink code that had a violation due to tabs. > >>>>> > >>>>> On Mon, Oct 26, 2015 at 6:56 PM, Suneel Marthi < > >> suneel.mar...@gmail.com > >>>> > >>>>> wrote: > >>>>>> 2 spaces is the convention that's followed on Mahout and Oryx. > >>>>>> > >>>>>> On Mon, Oct 26, 2015 at 1:42 PM, Till Rohrmann < > trohrm...@apache.org > >>> > >>>>> wrote: > >>>>>> > >>>>>>> Concerning question 2 Tabs vs. Spaces, in case of spaces we would > >> have > >>>>> to > >>>>>>> decide on the number of spaces, too. The Google Java style says to > >> use > >>>>> a 2 > >>>>>>> space indentation, which is in my opinion sufficient to distinguish > >>>>>>> different indentations levels from each other. Furthermore, it > would > >>>>> save > >>>>>>> some space. > >>>>>>> > >>>>>>> I would not vote -1 if we keep tabs. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Sat, Oct 24, 2015 at 8:33 PM, Henry Saputra < > >>> henry.sapu...@gmail.com > >>>>>> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> +1 for adding restriction for Javadoc at least at the header of > >>> public > >>>>>>>> classes and methods. > >>>>>>>> > >>>>>>>> We did the exercise in Twill and seemed to work pretty well. > >>>>>>>> > >>>>>>>> On Fri, Oct 23, 2015 at 1:34 AM, Maximilian Michels < > >> m...@apache.org> > >>>>>>>> wrote: > >>>>>>>>> I don't think lazily adding comments will work. However, I'm fine > >>>>> with > >>>>>>>>> adding all the checkstyle rules one module at a time (with a jira > >>>>>>>>> issue to keep track of the modules already converted). It's not > >>>>> going > >>>>>>>>> to happen that we lazily add comments because that's the reason > >> why > >>>>>>>>> comments are missing in the first place... > >>>>>>>>> > >>>>>>>>> On Fri, Oct 23, 2015 at 12:05 AM, Henry Saputra < > >>>>>>> henry.sapu...@gmail.com> > >>>>>>>> wrote: > >>>>>>>>>> Could we make certain rules to give warning instead of error? > >>>>>>>>>> > >>>>>>>>>> This would allow us to cherry-pick certain rules we would like > >>>>> people > >>>>>>>>>> to follow but not strictly enforced. > >>>>>>>>>> > >>>>>>>>>> - Henry > >>>>>>>>>> > >>>>>>>>>> On Thu, Oct 22, 2015 at 9:20 AM, Stephan Ewen <se...@apache.org > > > >>>>>>> wrote: > >>>>>>>>>>> I don't think a "let add comments to everything" effort gives > us > >>>>> good > >>>>>>>>>>> comments, actually. It just gives us checkmark comments that > >> make > >>>>> the > >>>>>>>> rules > >>>>>>>>>>> pass. > >>>>>>>>>>> > >>>>>>>>>>> On Thu, Oct 22, 2015 at 3:29 PM, Fabian Hueske < > >> fhue...@gmail.com > >>>>>> > >>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Sure, I don't expect it to be free. > >>>>>>>>>>>> But everybody should be aware of the cost of adding this code > >>>>> style, > >>>>>>>> i.e., > >>>>>>>>>>>> spending a huge amount of time on reformatting and documenting > >>>>> code. > >>>>>>>>>>>> > >>>>>>>>>>>> Alternatively, we could drop the JavaDocs rule and make the > >>>>>>> transition > >>>>>>>>>>>> significantly cheaper. > >>>>>>>>>>>> > >>>>>>>>>>>> 2015-10-22 15:24 GMT+02:00 Till Rohrmann < > trohrm...@apache.org > >>> : > >>>>>>>>>>>> > >>>>>>>>>>>>> There ain’t no such thing as a free lunch and code style. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Thu, Oct 22, 2015 at 3:13 PM, Maximilian Michels < > >>>>>>> m...@apache.org > >>>>>>>>> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> I think we have to document all these classes. Code Style > >>>>>>> doesn't > >>>>>>>> come > >>>>>>>>>>>>>> for free :) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Thu, Oct 22, 2015 at 3:09 PM, Fabian Hueske < > >>>>>>> fhue...@gmail.com > >>>>>>>>> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> Any ideas how to deal with the mandatory JavaDoc rule for > >>>>>>>> existing > >>>>>>>>>>>>> code? > >>>>>>>>>>>>>>> Just adding empty headers to make the checkstyle pass or > >>>>>>> start a > >>>>>>>>>>>>> serious > >>>>>>>>>>>>>>> effort to add the missing docs? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 2015-10-21 13:31 GMT+02:00 Matthias J. Sax < > >>>>> mj...@apache.org > >>>>>>>> : > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Agreed. That's the reason why I am in favor of using > >>>>> vanilla > >>>>>>>> Google > >>>>>>>>>>>>> code > >>>>>>>>>>>>>>>> style. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 10/21/2015 12:31 PM, Stephan Ewen wrote: > >>>>>>>>>>>>>>>>> We started out originally with mixed tab/spaces, but it > >>>>>>>> ended up > >>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>> people mixing spaces and tabs arbitrarily, and there is > >>>>>>>> little way > >>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>> enforce Matthias' specific suggestion via checkstyle. > >>>>>>>>>>>>>>>>> That's why we dropped spaces alltogether... > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Wed, Oct 21, 2015 at 12:03 PM, Gyula Fóra < > >>>>>>>>>>>> gyula.f...@gmail.com> > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I think the nice thing about a common codestyle is that > >>>>>>>> everyone > >>>>>>>>>>>>> can > >>>>>>>>>>>>>> set > >>>>>>>>>>>>>>>>>> the template in the IDE and use the formatting > >>>>> commands. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Matthias's suggestion makes this practically > >>>>> impossible so > >>>>>>>> -1 for > >>>>>>>>>>>>>> mixed > >>>>>>>>>>>>>>>>>> tabs/spaces from my side. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Matthias J. Sax <mj...@apache.org> ezt írta (időpont: > >>>>>>>> 2015. okt. > >>>>>>>>>>>>>> 21., > >>>>>>>>>>>>>>>> Sze, > >>>>>>>>>>>>>>>>>> 11:46): > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I actually like tabs a lot, however, in a "mixed" > >>>>> style > >>>>>>>> together > >>>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>>>> spaces. Example: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> myVar.callMethod(param1, // many more > >>>>>>>>>>>>>>>>>>> .................paramX); // the dots mark > >>>>> space > >>>>>>>>>>>> indention > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> indenting "paramX" with tabs does not give nice > >>>>> aliment. > >>>>>>>> Not > >>>>>>>>>>>> sure > >>>>>>>>>>>>> if > >>>>>>>>>>>>>>>>>>> this would be a feasible compromise to keeps tabs in > >>>>>>>> general, > >>>>>>>>>>>> but > >>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>> space for cases as above. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> If this in no feasible compromise, I would prefer > >>>>> space > >>>>>>> to > >>>>>>>> get > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> correct indention in examples as above. Even if this > >>>>>>>> result in a > >>>>>>>>>>>>>>>>>>> complete reformatting of the whole code. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Why this? Everybody can set this in it's IDE/editor as > >>>>>>>> he/she > >>>>>>>>>>>>>> wishes... > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> If we keep tabs, we will have to specify the line > >>>>>>> length > >>>>>>>>>>>>> relative > >>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>> tab > >>>>>>>>>>>>>>>>>>>>> size (like 4). > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> -Matthias > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 10/21/2015 11:06 AM, Ufuk Celebi wrote: > >>>>>>>>>>>>>>>>>>>> To summarize up to this point: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> - All are in favour of Google check style (with the > >>>>>>>> following > >>>>>>>>>>>>>> possible > >>>>>>>>>>>>>>>>>>>> exceptions) > >>>>>>>>>>>>>>>>>>>> - Proposed exceptions so far: > >>>>>>>>>>>>>>>>>>>> * Specific line length 100 vs. 120 characters > >>>>>>>>>>>>>>>>>>>> * Keep tabs instead converting to spaces (this > >>>>> would > >>>>>>>>>>>> translate > >>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>> skipping/coming up with some indentation rules as > >>>>> well) > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> If we keep tabs, we will have to specify the line > >>>>> length > >>>>>>>>>>>> relative > >>>>>>>>>>>>>> to a > >>>>>>>>>>>>>>>>>>> tab > >>>>>>>>>>>>>>>>>>>> size (like 4). > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Let’s keep the discussion going a little longer. I > >>>>> think > >>>>>>>> it has > >>>>>>>>>>>>>>>>>> proceeded > >>>>>>>>>>>>>>>>>>>> in a very reasonable manner so far. Thanks for this! > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> – Ufuk > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On Wed, Oct 21, 2015 at 10:29 AM, Fabian Hueske < > >>>>>>>>>>>>> fhue...@gmail.com > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks Max for checking the modifications by the > >>>>> Google > >>>>>>>> code > >>>>>>>>>>>>>> style. > >>>>>>>>>>>>>>>>>>>>> It is very good to know, that the impact on the code > >>>>>>> base > >>>>>>>>>>>> would > >>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>> too > >>>>>>>>>>>>>>>>>>>>> massive. If the Google code style would have touched > >>>>>>>> almost > >>>>>>>>>>>>> every > >>>>>>>>>>>>>>>>>> line, > >>>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>> would have been in favor of converting to spaces. > >>>>>>>> However, > >>>>>>>>>>>> your > >>>>>>>>>>>>>>>>>>> assessment > >>>>>>>>>>>>>>>>>>>>> is a strong argument to continue with tabs, IMO. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Regarding the line length limit, I personally find > >>>>> 100 > >>>>>>>> chars > >>>>>>>>>>>> too > >>>>>>>>>>>>>>>>>> narrow > >>>>>>>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>>>>>> would be +1 for having a limit. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> +1 for discussing the Scala style in a separate > >>>>> thread. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Fabian > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> 2015-10-20 18:12 GMT+02:00 Maximilian Michels < > >>>>>>>> m...@apache.org > >>>>>>>>>>>>> : > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I'm a little less excited about this. You might > >>>>> not be > >>>>>>>> aware > >>>>>>>>>>>>> but, > >>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>> a large portion of the source code, we already > >>>>> follow > >>>>>>>> the > >>>>>>>>>>>>> Google > >>>>>>>>>>>>>>>>>> style > >>>>>>>>>>>>>>>>>>>>>> guide. The main changes will be tabs->spaces and > >>>>>>> 80/100 > >>>>>>>>>>>>>> characters > >>>>>>>>>>>>>>>>>>>>>> line limit. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Out of curiosity, I ran the official Google Style > >>>>>>>> Checkstyle > >>>>>>>>>>>>>>>>>>>>>> configuration to confirm my suspicion: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>> > >> > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml > >>>>>>>>>>>>>>>>>>>>>> The changes are very little if we turn off line > >>>>> length > >>>>>>>> limit > >>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>> tabs-to-spaces conversion. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> There are some things I really like about the > >>>>> Google > >>>>>>>> style, > >>>>>>>>>>>>> e.g. > >>>>>>>>>>>>>>>>>> every > >>>>>>>>>>>>>>>>>>>>>> class has to have a JavaDoc and spaces after > >>>>> keywords > >>>>>>>> (can't > >>>>>>>>>>>>>> stand > >>>>>>>>>>>>>>>> if > >>>>>>>>>>>>>>>>>>>>>> there aren't any). I'm not sure if we should change > >>>>>>>> tabs to > >>>>>>>>>>>>>> spaces, > >>>>>>>>>>>>>>>>>>>>>> because it means touching almost every single line > >>>>> of > >>>>>>>> code. > >>>>>>>>>>>>>> However, > >>>>>>>>>>>>>>>>>>>>>> if we keep the tabs, we cannot make use of the > >>>>>>> different > >>>>>>>>>>>>>> indention > >>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>> case statements or wrapped lines...maybe that's a > >>>>>>>> compromise > >>>>>>>>>>>> we > >>>>>>>>>>>>>> can > >>>>>>>>>>>>>>>>>>>>>> live with. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> If we introduce the Google Style for Java, will we > >>>>>>> also > >>>>>>>>>>>> impose > >>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>>>>> stricter style check for Scala? IMHO the line > >>>>> length > >>>>>>> is > >>>>>>>> the > >>>>>>>>>>>>>>>> strictest > >>>>>>>>>>>>>>>>>>>>>> part of the Scala Checkstyle. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> On Tue, Oct 20, 2015 at 4:14 PM, Henry Saputra < > >>>>>>>>>>>>>>>>>>> henry.sapu...@gmail.com> > >>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>> 1) yes. Been dancing this issue for a while. Let's > >>>>>>>> pull the > >>>>>>>>>>>>>>>> trigger. > >>>>>>>>>>>>>>>>>>>>> Did > >>>>>>>>>>>>>>>>>>>>>>> the exercise with Tachyon while back and did help > >>>>>>>>>>>> readability > >>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>>> homogeneity of code. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> 2) +1 for Google Java style with documented > >>>>>>> exceptions > >>>>>>>> and > >>>>>>>>>>>>>>>>>> explanation > >>>>>>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>>>>> why. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> On Tuesday, October 20, 2015, Ufuk Celebi < > >>>>>>>> u...@apache.org> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> DISCLAIMER: This is not my personal idea, but a > >>>>>>>> community > >>>>>>>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>>>>>> from > >>>>>>>>>>>>>>>>>>>>>>>> some time ago. Don't kill the messenger. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> In March we were discussing issues with > >>>>>>> heterogeneity > >>>>>>>> of > >>>>>>>>>>>> the > >>>>>>>>>>>>>> code > >>>>>>>>>>>>>>>>>>> [1]. > >>>>>>>>>>>>>>>>>>>>>> The > >>>>>>>>>>>>>>>>>>>>>>>> summary is that we had a consensus to enforce a > >>>>>>>> stricter > >>>>>>>>>>>> code > >>>>>>>>>>>>>>>> style > >>>>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>>>> our > >>>>>>>>>>>>>>>>>>>>>>>> Java code base in order to make it easier to > >>>>> switch > >>>>>>>> between > >>>>>>>>>>>>>>>>>> projects > >>>>>>>>>>>>>>>>>>>>>> and to > >>>>>>>>>>>>>>>>>>>>>>>> have clear rules for new contributions. The main > >>>>>>>> proposal > >>>>>>>>>>>> in > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> last > >>>>>>>>>>>>>>>>>>>>>>>> discussion was to go with Google's Java code > >>>>> style. > >>>>>>>> Not all > >>>>>>>>>>>>>> were > >>>>>>>>>>>>>>>>>>> fully > >>>>>>>>>>>>>>>>>>>>>>>> satisfied with this, but still everyone agreed on > >>>>>>>> some kind > >>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>> style. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I think the upcoming 0.10 release is a good > >>>>> point to > >>>>>>>>>>>> finally > >>>>>>>>>>>>> go > >>>>>>>>>>>>>>>>>>>>> through > >>>>>>>>>>>>>>>>>>>>>>>> with these changes (right after the > >>>>>>>> release/branch-off). > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I propose to go with Google's Java code style > >>>>> [2] as > >>>>>>>>>>>> proposed > >>>>>>>>>>>>>>>>>>> earlier. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> PROs: > >>>>>>>>>>>>>>>>>>>>>>>> - Clear style guide available > >>>>>>>>>>>>>>>>>>>>>>>> - Tooling like checkstyle rules, IDE plugins > >>>>> already > >>>>>>>>>>>>> available > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> CONs: > >>>>>>>>>>>>>>>>>>>>>>>> - Fully breaks our current style > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> The main problem with this will be open pull > >>>>>>> requests, > >>>>>>>>>>>> which > >>>>>>>>>>>>>> will > >>>>>>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>>>>> harder > >>>>>>>>>>>>>>>>>>>>>>>> to merge after all the changes. On the other > >>>>> hand, > >>>>>>>> should > >>>>>>>>>>>>> pull > >>>>>>>>>>>>>>>>>>>>> requests > >>>>>>>>>>>>>>>>>>>>>>>> that have been open for a long time block this? > >>>>> Most > >>>>>>>> of the > >>>>>>>>>>>>>>>>>> important > >>>>>>>>>>>>>>>>>>>>>>>> changes will be merged for the release anyways. I > >>>>>>>> think in > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> long > >>>>>>>>>>>>>>>>>>>>> run > >>>>>>>>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>>>>>>>> will gain more than we loose by this (more > >>>>>>> homogenous > >>>>>>>> code, > >>>>>>>>>>>>>> clear > >>>>>>>>>>>>>>>>>>>>>> rules). > >>>>>>>>>>>>>>>>>>>>>>>> And it is questionable whether we will ever be > >>>>> able > >>>>>>>> to do > >>>>>>>>>>>>> such > >>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>>>> change > >>>>>>>>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>>>>>>>> the future if we cannot do it now. The project > >>>>> will > >>>>>>>> most > >>>>>>>>>>>>> likely > >>>>>>>>>>>>>>>>>> grow > >>>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>>>> attract more contributors, at which point it > >>>>> will be > >>>>>>>> even > >>>>>>>>>>>>>> harder > >>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>> do. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Please make sure to answer the following points > >>>>> in > >>>>>>> the > >>>>>>>>>>>>>> discussion: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> 1) Are you (still) in favour of enforcing > >>>>> stricter > >>>>>>>> rules on > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> Java > >>>>>>>>>>>>>>>>>>>>>>>> codebase? > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> 2) If yes, would you be OK with the Google's Java > >>>>>>> code > >>>>>>>>>>>> style? > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> – Ufuk > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> [1] > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>> > >> > http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3ccanc1h_von0b5omnwzxchtyzwhakeghbzvquyk7s9o2a36b8...@mail.gmail.com%3e > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> [2] > >>>>>>>> https://google.github.io/styleguide/javaguide.html > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>>> > >>> > >>> > >> > >
