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 > >>>>> > >>> > >> > > > >
