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
