[DISCUSS] Java code style

[Ufuk Celebi <uc...@apache.org>]

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@mail.gmail.com%3e

[2] https://google.github.io/styleguide/javaguide.html

Re: [DISCUSS] Java code style

["Matthias J. Sax" <mj...@apache.org>]

I am in favor of Google vanilla code style.

As far as I followed the discussion there will be no style that
everybody loves, but most people agree that there should be a unique
style. Thus, adjusting Google style does not give any benefits.


-Matthias

On 10/20/2015 03:36 PM, Stephan Ewen wrote:
> +1 for introducing a stricter style guide and starting with the Google
> style.
> 
> Should we have a separate discussion whether we take the Google style guide
> vanilla, or whether we make slight adjustments?
> 
> On Tue, Oct 20, 2015 at 3:26 PM, Till Rohrmann <tr...@apache.org> wrote:
> 
>> That's how I've understood Ufuk's mail. Everyone should also be aware that
>> the Google code style limits the number characters per line to either 80 or
>> 100. But I guess that everyone will read it himself.
>>
>> On Tue, Oct 20, 2015 at 3:15 PM, Stephan Ewen <se...@apache.org> wrote:
>>
>>> Just checking: Do we take Google's style guide as is, including spaces
>>> instead of tabs? I like the spaces, but that will make things hard...
>>>
>>> On Tue, Oct 20, 2015 at 3:01 PM, Gyula Fóra <gy...@gmail.com>
>> wrote:
>>>
>>>> +1 for both :)
>>>>
>>>> Till Rohrmann <tr...@apache.org> ezt írta (időpont: 2015. okt.
>> 20.,
>>> K,
>>>> 14:58):
>>>>
>>>>> I like the idea to have a bit stricter code style which will increase
>>>> code
>>>>> maintainability and makes it easier for people to go through the
>> code.
>>>>> Furthermore, it will relieve us from code style comments while
>>> reviewing
>>>>> PRs which can be quite cumbersome.
>>>>>
>>>>> Personally, I like the Google code style. Thus, +1 for both points.
>>>>>
>>>>> Just a remark: We should discuss the same for Flink's Scala style at
>>> some
>>>>> point.
>>>>>
>>>>> On Tue, Oct 20, 2015 at 2:54 PM, Márton Balassi <
>>>> balassi.marton@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> +1 for both
>>>>>>
>>>>>> As we are planning to restructure the maven projects at the point
>>> that
>>>>>> breaks the PRs anyway, so going on step further at this point in
>> time
>>>> is
>>>>>> reasonable for me.
>>>>>>
>>>>>> On Tue, Oct 20, 2015 at 2:37 PM, Matthias J. Sax <mjsax@apache.org
>>>
>>>>> wrote:
>>>>>>
>>>>>>> big +1 for both!
>>>>>>>
>>>>>>> On 10/20/2015 02:31 PM, Ufuk Celebi 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@mail.gmail.com%3e
>>>>>>>>
>>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

Re: [DISCUSS] Java code style

[Stephan Ewen <se...@apache.org>]

+1 for introducing a stricter style guide and starting with the Google
style.

Should we have a separate discussion whether we take the Google style guide
vanilla, or whether we make slight adjustments?

On Tue, Oct 20, 2015 at 3:26 PM, Till Rohrmann <tr...@apache.org> wrote:

> That's how I've understood Ufuk's mail. Everyone should also be aware that
> the Google code style limits the number characters per line to either 80 or
> 100. But I guess that everyone will read it himself.
>
> On Tue, Oct 20, 2015 at 3:15 PM, Stephan Ewen <se...@apache.org> wrote:
>
> > Just checking: Do we take Google's style guide as is, including spaces
> > instead of tabs? I like the spaces, but that will make things hard...
> >
> > On Tue, Oct 20, 2015 at 3:01 PM, Gyula Fóra <gy...@gmail.com>
> wrote:
> >
> > > +1 for both :)
> > >
> > > Till Rohrmann <tr...@apache.org> ezt írta (időpont: 2015. okt.
> 20.,
> > K,
> > > 14:58):
> > >
> > > > I like the idea to have a bit stricter code style which will increase
> > > code
> > > > maintainability and makes it easier for people to go through the
> code.
> > > > Furthermore, it will relieve us from code style comments while
> > reviewing
> > > > PRs which can be quite cumbersome.
> > > >
> > > > Personally, I like the Google code style. Thus, +1 for both points.
> > > >
> > > > Just a remark: We should discuss the same for Flink's Scala style at
> > some
> > > > point.
> > > >
> > > > On Tue, Oct 20, 2015 at 2:54 PM, Márton Balassi <
> > > balassi.marton@gmail.com>
> > > > wrote:
> > > >
> > > > > +1 for both
> > > > >
> > > > > As we are planning to restructure the maven projects at the point
> > that
> > > > > breaks the PRs anyway, so going on step further at this point in
> time
> > > is
> > > > > reasonable for me.
> > > > >
> > > > > On Tue, Oct 20, 2015 at 2:37 PM, Matthias J. Sax <mjsax@apache.org
> >
> > > > wrote:
> > > > >
> > > > > > big +1 for both!
> > > > > >
> > > > > > On 10/20/2015 02:31 PM, Ufuk Celebi 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@mail.gmail.com%3e
> > > > > > >
> > > > > > > [2] https://google.github.io/styleguide/javaguide.html
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Java code style

[Till Rohrmann <tr...@apache.org>]

That's how I've understood Ufuk's mail. Everyone should also be aware that
the Google code style limits the number characters per line to either 80 or
100. But I guess that everyone will read it himself.

On Tue, Oct 20, 2015 at 3:15 PM, Stephan Ewen <se...@apache.org> wrote:

> Just checking: Do we take Google's style guide as is, including spaces
> instead of tabs? I like the spaces, but that will make things hard...
>
> On Tue, Oct 20, 2015 at 3:01 PM, Gyula Fóra <gy...@gmail.com> wrote:
>
> > +1 for both :)
> >
> > Till Rohrmann <tr...@apache.org> ezt írta (időpont: 2015. okt. 20.,
> K,
> > 14:58):
> >
> > > I like the idea to have a bit stricter code style which will increase
> > code
> > > maintainability and makes it easier for people to go through the code.
> > > Furthermore, it will relieve us from code style comments while
> reviewing
> > > PRs which can be quite cumbersome.
> > >
> > > Personally, I like the Google code style. Thus, +1 for both points.
> > >
> > > Just a remark: We should discuss the same for Flink's Scala style at
> some
> > > point.
> > >
> > > On Tue, Oct 20, 2015 at 2:54 PM, Márton Balassi <
> > balassi.marton@gmail.com>
> > > wrote:
> > >
> > > > +1 for both
> > > >
> > > > As we are planning to restructure the maven projects at the point
> that
> > > > breaks the PRs anyway, so going on step further at this point in time
> > is
> > > > reasonable for me.
> > > >
> > > > On Tue, Oct 20, 2015 at 2:37 PM, Matthias J. Sax <mj...@apache.org>
> > > wrote:
> > > >
> > > > > big +1 for both!
> > > > >
> > > > > On 10/20/2015 02:31 PM, Ufuk Celebi 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@mail.gmail.com%3e
> > > > > >
> > > > > > [2] https://google.github.io/styleguide/javaguide.html
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Java code style

[Stephan Ewen <se...@apache.org>]

Just checking: Do we take Google's style guide as is, including spaces
instead of tabs? I like the spaces, but that will make things hard...

On Tue, Oct 20, 2015 at 3:01 PM, Gyula Fóra <gy...@gmail.com> wrote:

> +1 for both :)
>
> Till Rohrmann <tr...@apache.org> ezt írta (időpont: 2015. okt. 20., K,
> 14:58):
>
> > I like the idea to have a bit stricter code style which will increase
> code
> > maintainability and makes it easier for people to go through the code.
> > Furthermore, it will relieve us from code style comments while reviewing
> > PRs which can be quite cumbersome.
> >
> > Personally, I like the Google code style. Thus, +1 for both points.
> >
> > Just a remark: We should discuss the same for Flink's Scala style at some
> > point.
> >
> > On Tue, Oct 20, 2015 at 2:54 PM, Márton Balassi <
> balassi.marton@gmail.com>
> > wrote:
> >
> > > +1 for both
> > >
> > > As we are planning to restructure the maven projects at the point that
> > > breaks the PRs anyway, so going on step further at this point in time
> is
> > > reasonable for me.
> > >
> > > On Tue, Oct 20, 2015 at 2:37 PM, Matthias J. Sax <mj...@apache.org>
> > wrote:
> > >
> > > > big +1 for both!
> > > >
> > > > On 10/20/2015 02:31 PM, Ufuk Celebi 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@mail.gmail.com%3e
> > > > >
> > > > > [2] https://google.github.io/styleguide/javaguide.html
> > > > >
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Java code style

[Gyula Fóra <gy...@gmail.com>]

+1 for both :)

Till Rohrmann <tr...@apache.org> ezt írta (időpont: 2015. okt. 20., K,
14:58):

> I like the idea to have a bit stricter code style which will increase code
> maintainability and makes it easier for people to go through the code.
> Furthermore, it will relieve us from code style comments while reviewing
> PRs which can be quite cumbersome.
>
> Personally, I like the Google code style. Thus, +1 for both points.
>
> Just a remark: We should discuss the same for Flink's Scala style at some
> point.
>
> On Tue, Oct 20, 2015 at 2:54 PM, Márton Balassi <ba...@gmail.com>
> wrote:
>
> > +1 for both
> >
> > As we are planning to restructure the maven projects at the point that
> > breaks the PRs anyway, so going on step further at this point in time is
> > reasonable for me.
> >
> > On Tue, Oct 20, 2015 at 2:37 PM, Matthias J. Sax <mj...@apache.org>
> wrote:
> >
> > > big +1 for both!
> > >
> > > On 10/20/2015 02:31 PM, Ufuk Celebi 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@mail.gmail.com%3e
> > > >
> > > > [2] https://google.github.io/styleguide/javaguide.html
> > > >
> > >
> > >
> >
>

Re: [DISCUSS] Java code style

[Till Rohrmann <tr...@apache.org>]

I like the idea to have a bit stricter code style which will increase code
maintainability and makes it easier for people to go through the code.
Furthermore, it will relieve us from code style comments while reviewing
PRs which can be quite cumbersome.

Personally, I like the Google code style. Thus, +1 for both points.

Just a remark: We should discuss the same for Flink's Scala style at some
point.

On Tue, Oct 20, 2015 at 2:54 PM, Márton Balassi <ba...@gmail.com>
wrote:

> +1 for both
>
> As we are planning to restructure the maven projects at the point that
> breaks the PRs anyway, so going on step further at this point in time is
> reasonable for me.
>
> On Tue, Oct 20, 2015 at 2:37 PM, Matthias J. Sax <mj...@apache.org> wrote:
>
> > big +1 for both!
> >
> > On 10/20/2015 02:31 PM, Ufuk Celebi 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@mail.gmail.com%3e
> > >
> > > [2] https://google.github.io/styleguide/javaguide.html
> > >
> >
> >
>

Re: [DISCUSS] Java code style

[Márton Balassi <ba...@gmail.com>]

+1 for both

As we are planning to restructure the maven projects at the point that
breaks the PRs anyway, so going on step further at this point in time is
reasonable for me.

On Tue, Oct 20, 2015 at 2:37 PM, Matthias J. Sax <mj...@apache.org> wrote:

> big +1 for both!
>
> On 10/20/2015 02:31 PM, Ufuk Celebi 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@mail.gmail.com%3e
> >
> > [2] https://google.github.io/styleguide/javaguide.html
> >
>
>

Re: [DISCUSS] Java code style

["Matthias J. Sax" <mj...@apache.org>]

big +1 for both!

On 10/20/2015 02:31 PM, Ufuk Celebi 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@mail.gmail.com%3e
> 
> [2] https://google.github.io/styleguide/javaguide.html
> 

Re: [DISCUSS] Java code style

[Till Rohrmann <tr...@apache.org>]

I think that the line length limitation and the space indentation are the
two rules which are most controversial in the Flink community because so
far it has been done completely different. Thus, they would also inflict
most of the changes. However, I think that at least the line length
limitation (independent of the actual length to some extent) has a positive
effect on readability of the code. Usually it's easier for people to find
the next line if one doesn't have to do too much horizontal parsing.

I think it would be best to discuss the Scala style guide in a separate
thread. Since there does not exist an exhaustive official style guide for
Scala, it will require more work from our side to come up with one.

On Tue, Oct 20, 2015 at 6:12 PM, Maximilian Michels <mx...@apache.org> wrote:

> 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 <he...@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >>
> >> [2] https://google.github.io/styleguide/javaguide.html
> >>
>

Re: [DISCUSS] Java code style

[Robert Metzger <rm...@apache.org>]

+1 for the google style, but keeping tabs. I'm against a too narrow line
length limitation (at least 100)

On Thu, Oct 22, 2015 at 6:05 PM, Henry Saputra <he...@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 <fh...@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 <tr...@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 <mx...@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 <fh...@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.fora@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 <
> >> > fhueske@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 <
> mxm@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.saputra@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 <
> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >> > > >> >>>>>>>>
> >> > > >> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
> >> > > >> >>>>>>>>
> >> > > >> >>>>>>
> >> > > >> >>>>>
> >> > > >> >>>>
> >> > > >> >>>
> >> > > >> >>>
> >> > > >> >>
> >> > > >> >
> >> > > >>
> >> > > >>
> >> > >
> >> >
> >>
>

Re: [DISCUSS] Java code style

[Maximilian Michels <mx...@apache.org>]

Thanks for wrapping up the discussion, Fabian!

The tab size is adjustable in all the viewers I know of, e.g. DataSet
with tab size of 2 on GitHub:
https://github.com/apache/flink/blob/master/flink-java/src/main/java/org/apache/flink/api/java/DataSet.java?ts=2
You can even even use "less -x2 Sourcefile.java" to adjust the tab
size. Generally, developers should know about these things, so I don't
think tabs are a real issue.

The more important consideration in the tabs vs spaces debate seems to
be the preservation of the most recent Git line history. Spaces
destroy the most recent line history entirely. Tabs let us at least
keep parts of the most recent line history. If we care about that, we
should keep tabs.

On Tue, Nov 10, 2015 at 1:39 AM, Alexander Alexandrov
<al...@gmail.com> wrote:
> 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 <uc...@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 <fh...@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 <mx...@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.marthi@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 <
>> trohrmann@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.saputra@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 <
>> >> mxm@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.saputra@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 <sewen@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 <
>> >> fhueske@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 <
>> trohrmann@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 <
>> >>>>>>> mxm@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 <
>> >>>>>>> fhueske@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 <
>> >>>>> mjsax@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.fora@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 <
>> >>>>>>>>>>>>> fhueske@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 <
>> >>>>>>>> mxm@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.saputra@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 <
>> >>>>>>>> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> [2]
>> >>>>>>>> https://google.github.io/styleguide/javaguide.html
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>
>>
>>

Re: [DISCUSS] Java code style

[Alexander Alexandrov <al...@gmail.com>]

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 <uc...@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 <fh...@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 <mx...@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.marthi@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 <
> trohrmann@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.saputra@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 <
> >> mxm@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.saputra@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 <sewen@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 <
> >> fhueske@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 <
> trohrmann@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 <
> >>>>>>> mxm@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 <
> >>>>>>> fhueske@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 <
> >>>>> mjsax@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.fora@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 <
> >>>>>>>>>>>>> fhueske@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 <
> >>>>>>>> mxm@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.saputra@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 <
> >>>>>>>> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> [2]
> >>>>>>>> https://google.github.io/styleguide/javaguide.html
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
>
>

Re: [DISCUSS] Java code style

[Ufuk Celebi <uc...@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 <fh...@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 <mx...@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.marthi@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 <trohrmann@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.saputra@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 <
>> mxm@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.saputra@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 <
>> fhueske@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 <trohrmann@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 <
>>>>>>> mxm@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 <
>>>>>>> fhueske@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 <
>>>>> mjsax@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.fora@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 <
>>>>>>>>>>>>> fhueske@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 <
>>>>>>>> mxm@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.saputra@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 <
>>>>>>>> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> [2]
>>>>>>>> https://google.github.io/styleguide/javaguide.html
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 

Re: [DISCUSS] Java code style

[Fabian Hueske <fh...@gmail.com>]

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 <mx...@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.marthi@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 <trohrmann@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.saputra@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 <
> mxm@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.saputra@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 <
> fhueske@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 <trohrmann@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 <
> > >>>> mxm@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 <
> > >>>> fhueske@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 <
> > >> mjsax@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.fora@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 <
> > >>>>>>>>>> fhueske@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 <
> > >>>>> mxm@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.saputra@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 <
> > >>>>> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> [2]
> > >>>>> https://google.github.io/styleguide/javaguide.html
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>
> > >>>>
> > >>
> > >
> >
> >
>

Re: [DISCUSS] Java code style

[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 <mx...@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.marthi@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 <tr...@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.saputra@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 <mx...@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.saputra@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 <fhueske@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 <tr...@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 <
> >>>> mxm@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 <
> >>>> fhueske@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 <
> >> mjsax@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.fora@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 <
> >>>>>>>>>> fhueske@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 <
> >>>>> mxm@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.saputra@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 <
> >>>>> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> [2]
> >>>>> https://google.github.io/styleguide/javaguide.html
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>
> >>>>
> >>
> >
>
>

Re: [DISCUSS] Java code style

["Matthias J. Sax" <mj...@apache.org>]

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 <mx...@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 <su...@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 <tr...@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.saputra@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 <mx...@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.saputra@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 <fhueske@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 <tr...@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 <
>>>> mxm@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 <
>>>> fhueske@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 <
>> mjsax@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.fora@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 <
>>>>>>>>>> fhueske@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 <
>>>>> mxm@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.saputra@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 <
>>>>> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> [2]
>>>>> https://google.github.io/styleguide/javaguide.html
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>
>>
> 

Re: [DISCUSS] Java code style

[Fabian Hueske <fh...@gmail.com>]

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 <mx...@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 <su...@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 <tr...@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.saputra@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 <mx...@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.saputra@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 <fhueske@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 <tr...@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 <
> >> mxm@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 <
> >> fhueske@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 <
> mjsax@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.fora@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 <
> >> > >>>> > fhueske@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 <
> >> > mxm@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.saputra@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 <
> >> > uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >> > >>>> > > >> >>>>>>>>
> >> > >>>> > > >> >>>>>>>> [2]
> >> > https://google.github.io/styleguide/javaguide.html
> >> > >>>> > > >> >>>>>>>>
> >> > >>>> > > >> >>>>>>
> >> > >>>> > > >> >>>>>
> >> > >>>> > > >> >>>>
> >> > >>>> > > >> >>>
> >> > >>>> > > >> >>>
> >> > >>>> > > >> >>
> >> > >>>> > > >> >
> >> > >>>> > > >>
> >> > >>>> > > >>
> >> > >>>> > >
> >> > >>>> >
> >> > >>>>
> >> >
> >>
>

Re: [DISCUSS] Java code style

[Maximilian Michels <mx...@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 <su...@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 <tr...@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 <he...@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 <mx...@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.saputra@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 <fh...@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 <tr...@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 <
>> mxm@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 <
>> fhueske@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 <mjsax@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.fora@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 <
>> > >>>> > fhueske@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 <
>> > mxm@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.saputra@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 <
>> > uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>> > >>>> > > >> >>>>>>>>
>> > >>>> > > >> >>>>>>>> [2]
>> > https://google.github.io/styleguide/javaguide.html
>> > >>>> > > >> >>>>>>>>
>> > >>>> > > >> >>>>>>
>> > >>>> > > >> >>>>>
>> > >>>> > > >> >>>>
>> > >>>> > > >> >>>
>> > >>>> > > >> >>>
>> > >>>> > > >> >>
>> > >>>> > > >> >
>> > >>>> > > >>
>> > >>>> > > >>
>> > >>>> > >
>> > >>>> >
>> > >>>>
>> >
>>

Re: [DISCUSS] Java code style

[Suneel Marthi <su...@gmail.com>]

2 spaces is the convention that's followed on Mahout and Oryx.

On Mon, Oct 26, 2015 at 1:42 PM, Till Rohrmann <tr...@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 <he...@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 <mx...@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.saputra@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 <fh...@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 <tr...@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 <
> mxm@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 <
> fhueske@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 <mjsax@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.fora@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 <
> > >>>> > fhueske@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 <
> > mxm@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.saputra@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 <
> > uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> > >>>> > > >> >>>>>>>>
> > >>>> > > >> >>>>>>>> [2]
> > https://google.github.io/styleguide/javaguide.html
> > >>>> > > >> >>>>>>>>
> > >>>> > > >> >>>>>>
> > >>>> > > >> >>>>>
> > >>>> > > >> >>>>
> > >>>> > > >> >>>
> > >>>> > > >> >>>
> > >>>> > > >> >>
> > >>>> > > >> >
> > >>>> > > >>
> > >>>> > > >>
> > >>>> > >
> > >>>> >
> > >>>>
> >
>

Re: [DISCUSS] Java code style

[Till Rohrmann <tr...@apache.org>]

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 <he...@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 <mx...@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 <he...@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 <fh...@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 <tr...@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 <mxm@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 <fhueske@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.fora@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 <
> >>>> > fhueske@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 <
> mxm@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.saputra@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 <
> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >>>> > > >> >>>>>>>>
> >>>> > > >> >>>>>>>> [2]
> https://google.github.io/styleguide/javaguide.html
> >>>> > > >> >>>>>>>>
> >>>> > > >> >>>>>>
> >>>> > > >> >>>>>
> >>>> > > >> >>>>
> >>>> > > >> >>>
> >>>> > > >> >>>
> >>>> > > >> >>
> >>>> > > >> >
> >>>> > > >>
> >>>> > > >>
> >>>> > >
> >>>> >
> >>>>
>

Re: [DISCUSS] Java code style

[Henry Saputra <he...@gmail.com>]

+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 <mx...@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 <he...@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 <fh...@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 <tr...@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 <mx...@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 <fh...@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.fora@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 <
>>>> > fhueske@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 <mxm@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>>> > > >> >>>>>>>>
>>>> > > >> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
>>>> > > >> >>>>>>>>
>>>> > > >> >>>>>>
>>>> > > >> >>>>>
>>>> > > >> >>>>
>>>> > > >> >>>
>>>> > > >> >>>
>>>> > > >> >>
>>>> > > >> >
>>>> > > >>
>>>> > > >>
>>>> > >
>>>> >
>>>>

Re: [DISCUSS] Java code style

["Matthias J. Sax" <mj...@apache.org>]

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 <mj...@apache.org>:
> 
>> 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 <mj...@apache.org>:
>>>
>>>> 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 <
>>>>> vasilikikalavri@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 <fh...@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 <uc...@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 <mx...@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.saputra@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 <
>> fhueske@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 <trohrmann@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 <
>>>>>>> mxm@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 <
>>>>>> fhueske@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 <mjsax@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.fora@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 <
>>>>>>>>>>>>> fhueske@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 <
>>>>>>>> mxm@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.saputra@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 <
>>>>>>> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> [2]
>>>>>> https://google.github.io/styleguide/javaguide.html
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 

Re: [DISCUSS] Java code style

[Fabian Hueske <fh...@gmail.com>]

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 <mj...@apache.org>:

> 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 <mj...@apache.org>:
> >
> >> 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 <
> >>> vasilikikalavri@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 <fh...@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 <uc...@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 <mx...@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.saputra@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 <
> fhueske@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 <trohrmann@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 <
> >>>>> mxm@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 <
> >>>> fhueske@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 <mjsax@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.fora@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 <
> >>>>>>>>>>> fhueske@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 <
> >>>>>> mxm@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.saputra@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 <
> >>>>> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> [2]
> >>>> https://google.github.io/styleguide/javaguide.html
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
>
>

Re: [DISCUSS] Java code style

["Matthias J. Sax" <mj...@apache.org>]

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 <mj...@apache.org>:
> 
>> 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 <
>>> vasilikikalavri@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 <fh...@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 <uc...@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 <mx...@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.saputra@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 <fh...@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 <tr...@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 <
>>>>> mxm@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 <
>>>> fhueske@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.fora@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 <
>>>>>>>>>>> fhueske@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 <
>>>>>> mxm@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.saputra@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 <
>>>>> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> [2]
>>>> https://google.github.io/styleguide/javaguide.html
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
> 

Re: [DISCUSS] Java code style

[Fabian Hueske <fh...@gmail.com>]

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 <mj...@apache.org>:

> 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 <
> > vasilikikalavri@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 <fh...@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 <uc...@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 <mx...@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.saputra@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 <fh...@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 <tr...@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 <
> >>> mxm@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 <
> >> fhueske@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.fora@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 <
> >>>>>>>>> fhueske@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 <
> >>>> mxm@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.saputra@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 <
> >>> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> [2]
> >> https://google.github.io/styleguide/javaguide.html
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

Re: [DISCUSS] Java code style

["Matthias J. Sax" <mj...@apache.org>]

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 <
> vasilikikalavri@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 <fh...@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 <uc...@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 <mx...@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.saputra@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 <fh...@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 <tr...@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 <
>>> mxm@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 <
>> fhueske@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.fora@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 <
>>>>>>>>> fhueske@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 <
>>>> mxm@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.saputra@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 <
>>> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [2]
>> https://google.github.io/styleguide/javaguide.html
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>
>>>>
>>>
>>
> 

Re: [DISCUSS] Java code style

[Stephan Ewen <se...@apache.org>]

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 <
vasilikikalavri@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 <fh...@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 <uc...@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 <mx...@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.saputra@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 <fh...@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 <tr...@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 <
> > mxm@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 <
> fhueske@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.fora@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 <
> > > >>>>> fhueske@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 <
> > > mxm@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.saputra@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 <
> > uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [2]
> https://google.github.io/styleguide/javaguide.html
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > >
> > >
> >
>

Re: [DISCUSS] Java code style

[Vasiliki Kalavri <va...@gmail.com>]

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 <fh...@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 <uc...@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 <mx...@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.saputra@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 <fh...@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 <tr...@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 <
> mxm@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 <fhueske@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.fora@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 <
> > >>>>> fhueske@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 <
> > mxm@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.saputra@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 <
> uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> >
> >
>

Re: [DISCUSS] Java code style

[Fabian Hueske <fh...@gmail.com>]

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 <uc...@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 <mx...@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 <he...@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 <fh...@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 <tr...@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 <mx...@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 <fh...@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.fora@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 <
> >>>>> fhueske@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 <
> mxm@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
>
>

Re: [DISCUSS] Java code style

[Ufuk Celebi <uc...@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 <mx...@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 <he...@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 <fh...@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 <tr...@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 <mx...@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 <fh...@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.fora@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 <
>>>>> fhueske@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 <mxm@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>> 
>>>> 

Re: [DISCUSS] Java code style

[Maximilian Michels <mx...@apache.org>]

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 <he...@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 <fh...@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 <tr...@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 <mx...@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 <fh...@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.fora@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 <
>>> > fhueske@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 <mxm@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>> > > >> >>>>>>>>
>>> > > >> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
>>> > > >> >>>>>>>>
>>> > > >> >>>>>>
>>> > > >> >>>>>
>>> > > >> >>>>
>>> > > >> >>>
>>> > > >> >>>
>>> > > >> >>
>>> > > >> >
>>> > > >>
>>> > > >>
>>> > >
>>> >
>>>

Re: [DISCUSS] Java code style

[Henry Saputra <he...@gmail.com>]

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 <fh...@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 <tr...@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 <mx...@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 <fh...@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.fora@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 <
>> > fhueske@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 <mxm@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>> > > >> >>>>>>>>
>> > > >> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
>> > > >> >>>>>>>>
>> > > >> >>>>>>
>> > > >> >>>>>
>> > > >> >>>>
>> > > >> >>>
>> > > >> >>>
>> > > >> >>
>> > > >> >
>> > > >>
>> > > >>
>> > >
>> >
>>

Re: [DISCUSS] Java code style

[Ufuk Celebi <uc...@apache.org>]

I agree and don't think that it is possible to add good/valuable comments
to all the classes in a reasonable time frame. I would stage this effort to
add comments lazily as we touch components -or- as people are motivated to
add comments. We can add exclusions for this check per file (might be a
long list though ;)).

But as I see it, there is consensus about the value of this rule for new
code. There we can strictly enforce it.

On Thu, Oct 22, 2015 at 6:20 PM, 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 <fh...@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 <tr...@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 <mx...@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 <fh...@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.fora@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 <
> > > fhueske@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 <
> mxm@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.saputra@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 <uce@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
> > > > >> >>>>>>>>
> > > > >> >>>>>>
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>>
> > > > >> >>>
> > > > >> >>
> > > > >> >
> > > > >>
> > > > >>
> > > >
> > >
> >
>

Re: [DISCUSS] Java code style

[Stephan Ewen <se...@apache.org>]

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 <fh...@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 <tr...@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 <mx...@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 <fh...@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.fora@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 <
> > fhueske@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 <mxm@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> > > >> >>>>>>>>
> > > >> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
> > > >> >>>>>>>>
> > > >> >>>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>>
> > > >> >>>
> > > >> >>
> > > >> >
> > > >>
> > > >>
> > >
> >
>

Re: [DISCUSS] Java code style

[Fabian Hueske <fh...@gmail.com>]

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 <tr...@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 <mx...@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 <fh...@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 <gy...@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 <
> fhueske@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 <mx...@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> > >> >>>>>>>>
> > >> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
> > >> >>>>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>>
> > >> >>
> > >> >
> > >>
> > >>
> >
>

Re: [DISCUSS] Java code style

[Till Rohrmann <tr...@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 <mx...@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 <fh...@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 <gy...@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 <fhueske@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 <mx...@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >> >>>>>>>>
> >> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
> >> >>>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>
> >> >
> >>
> >>
>

Re: [DISCUSS] Java code style

[Maximilian Michels <mx...@apache.org>]

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 <fh...@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 <gy...@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 <fh...@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 <mx...@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>> >>>>>>>>
>> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
>> >>>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>>
>>

Re: [DISCUSS] Java code style

[Fabian Hueske <fh...@gmail.com>]

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 <gy...@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 <fh...@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 <mx...@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >>>>>>>>
> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>

Re: [DISCUSS] Java code style

["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 <gy...@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 <fh...@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 <mx...@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>>>>>>>
>>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 

Re: [DISCUSS] Java code style

[Stephan Ewen <se...@apache.org>]

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 <gy...@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 <fh...@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 <mx...@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> > >>>>>
> > >>>>> [2] https://google.github.io/styleguide/javaguide.html
> > >>>>>
> > >>>
> > >>
> > >
> >
> >
>

Re: [DISCUSS] Java code style

[Gyula Fóra <gy...@gmail.com>]

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 <fh...@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 <mx...@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.saputra@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >>>>>
> >>>>> [2] https://google.github.io/styleguide/javaguide.html
> >>>>>
> >>>
> >>
> >
>
>

Re: [DISCUSS] Java code style

["Matthias J. Sax" <mj...@apache.org>]

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 <fh...@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 <mx...@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 <he...@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>>>>
>>>>> [2] https://google.github.io/styleguide/javaguide.html
>>>>>
>>>
>>
> 

Re: [DISCUSS] Java code style

[Ufuk Celebi <uc...@apache.org>]

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 <fh...@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 <mx...@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 <he...@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> > >>
> > >> [2] https://google.github.io/styleguide/javaguide.html
> > >>
> >
>

Re: [DISCUSS] Java code style

[Fabian Hueske <fh...@gmail.com>]

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 <mx...@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 <he...@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
> >>
> >> [2] https://google.github.io/styleguide/javaguide.html
> >>
>

Re: [DISCUSS] Java code style

[Maximilian Michels <mx...@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 <he...@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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>
>> [2] https://google.github.io/styleguide/javaguide.html
>>

Re: [DISCUSS] Java code style

[Henry Saputra <he...@gmail.com>]

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 <uc...@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_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>
> [2] https://google.github.io/styleguide/javaguide.html
>