[DISCUSS] Java code style

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Java code style

Ufuk Celebi-2
DISCLAIMER: This is not my personal idea, but a community discussion from
some time ago. Don't kill the messenger.

In March we were discussing issues with heterogeneity of the code [1]. The
summary is that we had a consensus to enforce a stricter code style on our
Java code base in order to make it easier to switch between projects and to
have clear rules for new contributions. The main proposal in the last
discussion was to go with Google's Java code style. Not all were fully
satisfied with this, but still everyone agreed on some kind of style.

I think the upcoming 0.10 release is a good point to finally go through
with these changes (right after the release/branch-off).

I propose to go with Google's Java code style [2] as proposed earlier.

PROs:
- Clear style guide available
- Tooling like checkstyle rules, IDE plugins already available

CONs:
- Fully breaks our current style

The main problem with this will be open pull requests, which will be harder
to merge after all the changes. On the other hand, should pull requests
that have been open for a long time block this? Most of the important
changes will be merged for the release anyways. I think in the long run we
will gain more than we loose by this (more homogenous code, clear rules).
And it is questionable whether we will ever be able to do such a change in
the future if we cannot do it now. The project will most likely grow and
attract more contributors, at which point it will be even harder to do.

Please make sure to answer the following points in the discussion:

1) Are you (still) in favour of enforcing stricter rules on the Java
codebase?

2) If yes, would you be OK with the Google's Java code style?

– Ufuk

[1]
http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e

[2] https://google.github.io/styleguide/javaguide.html
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Matthias J. Sax-2
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@...%3e
>
> [2] https://google.github.io/styleguide/javaguide.html
>


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Márton Balassi
+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 <[hidden email]> 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@...%3e
> >
> > [2] https://google.github.io/styleguide/javaguide.html
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Till Rohrmann
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 <[hidden email]>
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 <[hidden email]> 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@...%3e
> > >
> > > [2] https://google.github.io/styleguide/javaguide.html
> > >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Gyula Fóra
+1 for both :)

Till Rohrmann <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> 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@...%3e
> > > >
> > > > [2] https://google.github.io/styleguide/javaguide.html
> > > >
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Stephan Ewen
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 <[hidden email]> wrote:

> +1 for both :)
>
> Till Rohrmann <[hidden email]> 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 <
> [hidden email]>
> > 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 <[hidden email]>
> > 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@...%3e
> > > > >
> > > > > [2] https://google.github.io/styleguide/javaguide.html
> > > > >
> > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Till Rohrmann
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 <[hidden email]> 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 <[hidden email]> wrote:
>
> > +1 for both :)
> >
> > Till Rohrmann <[hidden email]> 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 <
> > [hidden email]>
> > > 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 <[hidden email]>
> > > 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@...%3e
> > > > > >
> > > > > > [2] https://google.github.io/styleguide/javaguide.html
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Stephan Ewen
+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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> > > +1 for both :)
> > >
> > > Till Rohrmann <[hidden email]> 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 <
> > > [hidden email]>
> > > > 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 <[hidden email]
> >
> > > > 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@...%3e
> > > > > > >
> > > > > > > [2] https://google.github.io/styleguide/javaguide.html
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Matthias J. Sax-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>>>
>>>> +1 for both :)
>>>>
>>>> Till Rohrmann <[hidden email]> 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 <
>>>> [hidden email]>
>>>>> 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 <[hidden email]
>>>
>>>>> 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@...%3e
>>>>>>>>
>>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Henry Saputra
In reply to this post by Ufuk Celebi-2
1) yes. Been dancing this issue for a while. Let's pull the trigger. Did
the exercise with Tachyon while back and did help readability and
homogeneity of code.

2) +1 for Google Java style with documented exceptions and explanation on
why.

On Tuesday, October 20, 2015, Ufuk Celebi <[hidden email]> wrote:

> DISCLAIMER: This is not my personal idea, but a community discussion from
> some time ago. Don't kill the messenger.
>
> In March we were discussing issues with heterogeneity of the code [1]. The
> summary is that we had a consensus to enforce a stricter code style on our
> Java code base in order to make it easier to switch between projects and to
> have clear rules for new contributions. The main proposal in the last
> discussion was to go with Google's Java code style. Not all were fully
> satisfied with this, but still everyone agreed on some kind of style.
>
> I think the upcoming 0.10 release is a good point to finally go through
> with these changes (right after the release/branch-off).
>
> I propose to go with Google's Java code style [2] as proposed earlier.
>
> PROs:
> - Clear style guide available
> - Tooling like checkstyle rules, IDE plugins already available
>
> CONs:
> - Fully breaks our current style
>
> The main problem with this will be open pull requests, which will be harder
> to merge after all the changes. On the other hand, should pull requests
> that have been open for a long time block this? Most of the important
> changes will be merged for the release anyways. I think in the long run we
> will gain more than we loose by this (more homogenous code, clear rules).
> And it is questionable whether we will ever be able to do such a change in
> the future if we cannot do it now. The project will most likely grow and
> attract more contributors, at which point it will be even harder to do.
>
> Please make sure to answer the following points in the discussion:
>
> 1) Are you (still) in favour of enforcing stricter rules on the Java
> codebase?
>
> 2) If yes, would you be OK with the Google's Java code style?
>
> – Ufuk
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e
>
> [2] https://google.github.io/styleguide/javaguide.html
>
mxm
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

mxm
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 <[hidden email]> wrote:

> 1) yes. Been dancing this issue for a while. Let's pull the trigger. Did
> the exercise with Tachyon while back and did help readability and
> homogeneity of code.
>
> 2) +1 for Google Java style with documented exceptions and explanation on
> why.
>
> On Tuesday, October 20, 2015, Ufuk Celebi <[hidden email]> wrote:
>
>> DISCLAIMER: This is not my personal idea, but a community discussion from
>> some time ago. Don't kill the messenger.
>>
>> In March we were discussing issues with heterogeneity of the code [1]. The
>> summary is that we had a consensus to enforce a stricter code style on our
>> Java code base in order to make it easier to switch between projects and to
>> have clear rules for new contributions. The main proposal in the last
>> discussion was to go with Google's Java code style. Not all were fully
>> satisfied with this, but still everyone agreed on some kind of style.
>>
>> I think the upcoming 0.10 release is a good point to finally go through
>> with these changes (right after the release/branch-off).
>>
>> I propose to go with Google's Java code style [2] as proposed earlier.
>>
>> PROs:
>> - Clear style guide available
>> - Tooling like checkstyle rules, IDE plugins already available
>>
>> CONs:
>> - Fully breaks our current style
>>
>> The main problem with this will be open pull requests, which will be harder
>> to merge after all the changes. On the other hand, should pull requests
>> that have been open for a long time block this? Most of the important
>> changes will be merged for the release anyways. I think in the long run we
>> will gain more than we loose by this (more homogenous code, clear rules).
>> And it is questionable whether we will ever be able to do such a change in
>> the future if we cannot do it now. The project will most likely grow and
>> attract more contributors, at which point it will be even harder to do.
>>
>> Please make sure to answer the following points in the discussion:
>>
>> 1) Are you (still) in favour of enforcing stricter rules on the Java
>> codebase?
>>
>> 2) If yes, would you be OK with the Google's Java code style?
>>
>> – Ufuk
>>
>> [1]
>>
>> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e
>>
>> [2] https://google.github.io/styleguide/javaguide.html
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Till Rohrmann
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 <[hidden email]> 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 <[hidden email]>
> wrote:
> > 1) yes. Been dancing this issue for a while. Let's pull the trigger. Did
> > the exercise with Tachyon while back and did help readability and
> > homogeneity of code.
> >
> > 2) +1 for Google Java style with documented exceptions and explanation on
> > why.
> >
> > On Tuesday, October 20, 2015, Ufuk Celebi <[hidden email]> wrote:
> >
> >> DISCLAIMER: This is not my personal idea, but a community discussion
> from
> >> some time ago. Don't kill the messenger.
> >>
> >> In March we were discussing issues with heterogeneity of the code [1].
> The
> >> summary is that we had a consensus to enforce a stricter code style on
> our
> >> Java code base in order to make it easier to switch between projects
> and to
> >> have clear rules for new contributions. The main proposal in the last
> >> discussion was to go with Google's Java code style. Not all were fully
> >> satisfied with this, but still everyone agreed on some kind of style.
> >>
> >> I think the upcoming 0.10 release is a good point to finally go through
> >> with these changes (right after the release/branch-off).
> >>
> >> I propose to go with Google's Java code style [2] as proposed earlier.
> >>
> >> PROs:
> >> - Clear style guide available
> >> - Tooling like checkstyle rules, IDE plugins already available
> >>
> >> CONs:
> >> - Fully breaks our current style
> >>
> >> The main problem with this will be open pull requests, which will be
> harder
> >> to merge after all the changes. On the other hand, should pull requests
> >> that have been open for a long time block this? Most of the important
> >> changes will be merged for the release anyways. I think in the long run
> we
> >> will gain more than we loose by this (more homogenous code, clear
> rules).
> >> And it is questionable whether we will ever be able to do such a change
> in
> >> the future if we cannot do it now. The project will most likely grow and
> >> attract more contributors, at which point it will be even harder to do.
> >>
> >> Please make sure to answer the following points in the discussion:
> >>
> >> 1) Are you (still) in favour of enforcing stricter rules on the Java
> >> codebase?
> >>
> >> 2) If yes, would you be OK with the Google's Java code style?
> >>
> >> – Ufuk
> >>
> >> [1]
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e
> >>
> >> [2] https://google.github.io/styleguide/javaguide.html
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Fabian Hueske-2
In reply to this post by mxm
Thanks Max for checking the modifications by the Google code style.
It is very good to know, that the impact on the code base would not be too
massive. If the Google code style would have touched almost every line, I
would have been in favor of converting to spaces. However, your assessment
is a strong argument to continue with tabs, IMO.

Regarding the line length limit, I personally find 100 chars too narrow but
would be +1 for having a limit.

+1 for discussing the Scala style in a separate thread.

Fabian

2015-10-20 18:12 GMT+02:00 Maximilian Michels <[hidden email]>:

> I'm a little less excited about this. You might not be aware but, for
> a large portion of the source code, we already follow the 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 <[hidden email]>
> wrote:
> > 1) yes. Been dancing this issue for a while. Let's pull the trigger. Did
> > the exercise with Tachyon while back and did help readability and
> > homogeneity of code.
> >
> > 2) +1 for Google Java style with documented exceptions and explanation on
> > why.
> >
> > On Tuesday, October 20, 2015, Ufuk Celebi <[hidden email]> wrote:
> >
> >> DISCLAIMER: This is not my personal idea, but a community discussion
> from
> >> some time ago. Don't kill the messenger.
> >>
> >> In March we were discussing issues with heterogeneity of the code [1].
> The
> >> summary is that we had a consensus to enforce a stricter code style on
> our
> >> Java code base in order to make it easier to switch between projects
> and to
> >> have clear rules for new contributions. The main proposal in the last
> >> discussion was to go with Google's Java code style. Not all were fully
> >> satisfied with this, but still everyone agreed on some kind of style.
> >>
> >> I think the upcoming 0.10 release is a good point to finally go through
> >> with these changes (right after the release/branch-off).
> >>
> >> I propose to go with Google's Java code style [2] as proposed earlier.
> >>
> >> PROs:
> >> - Clear style guide available
> >> - Tooling like checkstyle rules, IDE plugins already available
> >>
> >> CONs:
> >> - Fully breaks our current style
> >>
> >> The main problem with this will be open pull requests, which will be
> harder
> >> to merge after all the changes. On the other hand, should pull requests
> >> that have been open for a long time block this? Most of the important
> >> changes will be merged for the release anyways. I think in the long run
> we
> >> will gain more than we loose by this (more homogenous code, clear
> rules).
> >> And it is questionable whether we will ever be able to do such a change
> in
> >> the future if we cannot do it now. The project will most likely grow and
> >> attract more contributors, at which point it will be even harder to do.
> >>
> >> Please make sure to answer the following points in the discussion:
> >>
> >> 1) Are you (still) in favour of enforcing stricter rules on the Java
> >> codebase?
> >>
> >> 2) If yes, would you be OK with the Google's Java code style?
> >>
> >> – Ufuk
> >>
> >> [1]
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e
> >>
> >> [2] https://google.github.io/styleguide/javaguide.html
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Ufuk Celebi-2
To summarize up to this point:

- All are in favour of Google check style (with the following possible
exceptions)
- Proposed exceptions so far:
  * Specific line length 100 vs. 120 characters
  * Keep tabs instead converting to spaces (this would translate to
skipping/coming up with some indentation rules as well)

If we keep tabs, we will have to specify the line length relative to a tab
size (like 4).

Let’s keep the discussion going a little longer. I think it has proceeded
in a very reasonable manner so far. Thanks for this!

– Ufuk

On Wed, Oct 21, 2015 at 10:29 AM, Fabian Hueske <[hidden email]> wrote:

> Thanks Max for checking the modifications by the Google code style.
> It is very good to know, that the impact on the code base would not be too
> massive. If the Google code style would have touched almost every line, I
> would have been in favor of converting to spaces. However, your assessment
> is a strong argument to continue with tabs, IMO.
>
> Regarding the line length limit, I personally find 100 chars too narrow but
> would be +1 for having a limit.
>
> +1 for discussing the Scala style in a separate thread.
>
> Fabian
>
> 2015-10-20 18:12 GMT+02:00 Maximilian Michels <[hidden email]>:
>
> > I'm a little less excited about this. You might not be aware but, for
> > a large portion of the source code, we already follow the 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 <[hidden email]>
> > wrote:
> > > 1) yes. Been dancing this issue for a while. Let's pull the trigger.
> Did
> > > the exercise with Tachyon while back and did help readability and
> > > homogeneity of code.
> > >
> > > 2) +1 for Google Java style with documented exceptions and explanation
> on
> > > why.
> > >
> > > On Tuesday, October 20, 2015, Ufuk Celebi <[hidden email]> wrote:
> > >
> > >> DISCLAIMER: This is not my personal idea, but a community discussion
> > from
> > >> some time ago. Don't kill the messenger.
> > >>
> > >> In March we were discussing issues with heterogeneity of the code [1].
> > The
> > >> summary is that we had a consensus to enforce a stricter code style on
> > our
> > >> Java code base in order to make it easier to switch between projects
> > and to
> > >> have clear rules for new contributions. The main proposal in the last
> > >> discussion was to go with Google's Java code style. Not all were fully
> > >> satisfied with this, but still everyone agreed on some kind of style.
> > >>
> > >> I think the upcoming 0.10 release is a good point to finally go
> through
> > >> with these changes (right after the release/branch-off).
> > >>
> > >> I propose to go with Google's Java code style [2] as proposed earlier.
> > >>
> > >> PROs:
> > >> - Clear style guide available
> > >> - Tooling like checkstyle rules, IDE plugins already available
> > >>
> > >> CONs:
> > >> - Fully breaks our current style
> > >>
> > >> The main problem with this will be open pull requests, which will be
> > harder
> > >> to merge after all the changes. On the other hand, should pull
> requests
> > >> that have been open for a long time block this? Most of the important
> > >> changes will be merged for the release anyways. I think in the long
> run
> > we
> > >> will gain more than we loose by this (more homogenous code, clear
> > rules).
> > >> And it is questionable whether we will ever be able to do such a
> change
> > in
> > >> the future if we cannot do it now. The project will most likely grow
> and
> > >> attract more contributors, at which point it will be even harder to
> do.
> > >>
> > >> Please make sure to answer the following points in the discussion:
> > >>
> > >> 1) Are you (still) in favour of enforcing stricter rules on the Java
> > >> codebase?
> > >>
> > >> 2) If yes, would you be OK with the Google's Java code style?
> > >>
> > >> – Ufuk
> > >>
> > >> [1]
> > >>
> > >>
> >
> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e
> > >>
> > >> [2] https://google.github.io/styleguide/javaguide.html
> > >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Matthias J. Sax-2
I actually like tabs a lot, however, in a "mixed" style together with
spaces. Example:

        myVar.callMethod(param1, // many more
        .................paramX); // the dots mark space indention

indenting "paramX" with tabs does not give nice aliment. Not sure if
this would be a feasible compromise to keeps tabs in general, but use
space for cases as above.

If this in no feasible compromise, I would prefer space to get the
correct indention in examples as above. Even if this result in a
complete reformatting of the whole code.


Why this? Everybody can set this in it's IDE/editor as he/she wishes...

>> If we keep tabs, we will have to specify the line length relative to a tab
>> size (like 4).


-Matthias





On 10/21/2015 11:06 AM, Ufuk Celebi wrote:

> To summarize up to this point:
>
> - All are in favour of Google check style (with the following possible
> exceptions)
> - Proposed exceptions so far:
>   * Specific line length 100 vs. 120 characters
>   * Keep tabs instead converting to spaces (this would translate to
> skipping/coming up with some indentation rules as well)
>
> If we keep tabs, we will have to specify the line length relative to a tab
> size (like 4).
>
> Let’s keep the discussion going a little longer. I think it has proceeded
> in a very reasonable manner so far. Thanks for this!
>
> – Ufuk
>
> On Wed, Oct 21, 2015 at 10:29 AM, Fabian Hueske <[hidden email]> wrote:
>
>> Thanks Max for checking the modifications by the Google code style.
>> It is very good to know, that the impact on the code base would not be too
>> massive. If the Google code style would have touched almost every line, I
>> would have been in favor of converting to spaces. However, your assessment
>> is a strong argument to continue with tabs, IMO.
>>
>> Regarding the line length limit, I personally find 100 chars too narrow but
>> would be +1 for having a limit.
>>
>> +1 for discussing the Scala style in a separate thread.
>>
>> Fabian
>>
>> 2015-10-20 18:12 GMT+02:00 Maximilian Michels <[hidden email]>:
>>
>>> I'm a little less excited about this. You might not be aware but, for
>>> a large portion of the source code, we already follow the 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 <[hidden email]>
>>> wrote:
>>>> 1) yes. Been dancing this issue for a while. Let's pull the trigger.
>> Did
>>>> the exercise with Tachyon while back and did help readability and
>>>> homogeneity of code.
>>>>
>>>> 2) +1 for Google Java style with documented exceptions and explanation
>> on
>>>> why.
>>>>
>>>> On Tuesday, October 20, 2015, Ufuk Celebi <[hidden email]> wrote:
>>>>
>>>>> DISCLAIMER: This is not my personal idea, but a community discussion
>>> from
>>>>> some time ago. Don't kill the messenger.
>>>>>
>>>>> In March we were discussing issues with heterogeneity of the code [1].
>>> The
>>>>> summary is that we had a consensus to enforce a stricter code style on
>>> our
>>>>> Java code base in order to make it easier to switch between projects
>>> and to
>>>>> have clear rules for new contributions. The main proposal in the last
>>>>> discussion was to go with Google's Java code style. Not all were fully
>>>>> satisfied with this, but still everyone agreed on some kind of style.
>>>>>
>>>>> I think the upcoming 0.10 release is a good point to finally go
>> through
>>>>> with these changes (right after the release/branch-off).
>>>>>
>>>>> I propose to go with Google's Java code style [2] as proposed earlier.
>>>>>
>>>>> PROs:
>>>>> - Clear style guide available
>>>>> - Tooling like checkstyle rules, IDE plugins already available
>>>>>
>>>>> CONs:
>>>>> - Fully breaks our current style
>>>>>
>>>>> The main problem with this will be open pull requests, which will be
>>> harder
>>>>> to merge after all the changes. On the other hand, should pull
>> requests
>>>>> that have been open for a long time block this? Most of the important
>>>>> changes will be merged for the release anyways. I think in the long
>> run
>>> we
>>>>> will gain more than we loose by this (more homogenous code, clear
>>> rules).
>>>>> And it is questionable whether we will ever be able to do such a
>> change
>>> in
>>>>> the future if we cannot do it now. The project will most likely grow
>> and
>>>>> attract more contributors, at which point it will be even harder to
>> do.
>>>>>
>>>>> Please make sure to answer the following points in the discussion:
>>>>>
>>>>> 1) Are you (still) in favour of enforcing stricter rules on the Java
>>>>> codebase?
>>>>>
>>>>> 2) If yes, would you be OK with the Google's Java code style?
>>>>>
>>>>> – Ufuk
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>
>> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e
>>>>>
>>>>> [2] https://google.github.io/styleguide/javaguide.html
>>>>>
>>>
>>
>


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Gyula Fóra
I think the nice thing about a common codestyle is that everyone can set
the template in the IDE and use the formatting commands.

Matthias's suggestion makes this practically impossible so -1 for mixed
tabs/spaces from my side.

Matthias J. Sax <[hidden email]> ezt írta (időpont: 2015. okt. 21., Sze,
11:46):

> I actually like tabs a lot, however, in a "mixed" style together with
> spaces. Example:
>
>         myVar.callMethod(param1, // many more
>         .................paramX); // the dots mark space indention
>
> indenting "paramX" with tabs does not give nice aliment. Not sure if
> this would be a feasible compromise to keeps tabs in general, but use
> space for cases as above.
>
> If this in no feasible compromise, I would prefer space to get the
> correct indention in examples as above. Even if this result in a
> complete reformatting of the whole code.
>
>
> Why this? Everybody can set this in it's IDE/editor as he/she wishes...
>
> >> If we keep tabs, we will have to specify the line length relative to a
> tab
> >> size (like 4).
>
>
> -Matthias
>
>
>
>
>
> On 10/21/2015 11:06 AM, Ufuk Celebi wrote:
> > To summarize up to this point:
> >
> > - All are in favour of Google check style (with the following possible
> > exceptions)
> > - Proposed exceptions so far:
> >   * Specific line length 100 vs. 120 characters
> >   * Keep tabs instead converting to spaces (this would translate to
> > skipping/coming up with some indentation rules as well)
> >
> > If we keep tabs, we will have to specify the line length relative to a
> tab
> > size (like 4).
> >
> > Let’s keep the discussion going a little longer. I think it has proceeded
> > in a very reasonable manner so far. Thanks for this!
> >
> > – Ufuk
> >
> > On Wed, Oct 21, 2015 at 10:29 AM, Fabian Hueske <[hidden email]>
> wrote:
> >
> >> Thanks Max for checking the modifications by the Google code style.
> >> It is very good to know, that the impact on the code base would not be
> too
> >> massive. If the Google code style would have touched almost every line,
> I
> >> would have been in favor of converting to spaces. However, your
> assessment
> >> is a strong argument to continue with tabs, IMO.
> >>
> >> Regarding the line length limit, I personally find 100 chars too narrow
> but
> >> would be +1 for having a limit.
> >>
> >> +1 for discussing the Scala style in a separate thread.
> >>
> >> Fabian
> >>
> >> 2015-10-20 18:12 GMT+02:00 Maximilian Michels <[hidden email]>:
> >>
> >>> I'm a little less excited about this. You might not be aware but, for
> >>> a large portion of the source code, we already follow the 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 <
> [hidden email]>
> >>> wrote:
> >>>> 1) yes. Been dancing this issue for a while. Let's pull the trigger.
> >> Did
> >>>> the exercise with Tachyon while back and did help readability and
> >>>> homogeneity of code.
> >>>>
> >>>> 2) +1 for Google Java style with documented exceptions and explanation
> >> on
> >>>> why.
> >>>>
> >>>> On Tuesday, October 20, 2015, Ufuk Celebi <[hidden email]> wrote:
> >>>>
> >>>>> DISCLAIMER: This is not my personal idea, but a community discussion
> >>> from
> >>>>> some time ago. Don't kill the messenger.
> >>>>>
> >>>>> In March we were discussing issues with heterogeneity of the code
> [1].
> >>> The
> >>>>> summary is that we had a consensus to enforce a stricter code style
> on
> >>> our
> >>>>> Java code base in order to make it easier to switch between projects
> >>> and to
> >>>>> have clear rules for new contributions. The main proposal in the last
> >>>>> discussion was to go with Google's Java code style. Not all were
> fully
> >>>>> satisfied with this, but still everyone agreed on some kind of style.
> >>>>>
> >>>>> I think the upcoming 0.10 release is a good point to finally go
> >> through
> >>>>> with these changes (right after the release/branch-off).
> >>>>>
> >>>>> I propose to go with Google's Java code style [2] as proposed
> earlier.
> >>>>>
> >>>>> PROs:
> >>>>> - Clear style guide available
> >>>>> - Tooling like checkstyle rules, IDE plugins already available
> >>>>>
> >>>>> CONs:
> >>>>> - Fully breaks our current style
> >>>>>
> >>>>> The main problem with this will be open pull requests, which will be
> >>> harder
> >>>>> to merge after all the changes. On the other hand, should pull
> >> requests
> >>>>> that have been open for a long time block this? Most of the important
> >>>>> changes will be merged for the release anyways. I think in the long
> >> run
> >>> we
> >>>>> will gain more than we loose by this (more homogenous code, clear
> >>> rules).
> >>>>> And it is questionable whether we will ever be able to do such a
> >> change
> >>> in
> >>>>> the future if we cannot do it now. The project will most likely grow
> >> and
> >>>>> attract more contributors, at which point it will be even harder to
> >> do.
> >>>>>
> >>>>> Please make sure to answer the following points in the discussion:
> >>>>>
> >>>>> 1) Are you (still) in favour of enforcing stricter rules on the Java
> >>>>> codebase?
> >>>>>
> >>>>> 2) If yes, would you be OK with the Google's Java code style?
> >>>>>
> >>>>> – Ufuk
> >>>>>
> >>>>> [1]
> >>>>>
> >>>>>
> >>>
> >>
> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e
> >>>>>
> >>>>> [2] https://google.github.io/styleguide/javaguide.html
> >>>>>
> >>>
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Stephan Ewen
We started out originally with mixed tab/spaces, but it ended up with
people mixing spaces and tabs arbitrarily, and there is little way to
enforce Matthias' specific suggestion via checkstyle.
That's why we dropped spaces alltogether...

On Wed, Oct 21, 2015 at 12:03 PM, Gyula Fóra <[hidden email]> wrote:

> I think the nice thing about a common codestyle is that everyone can set
> the template in the IDE and use the formatting commands.
>
> Matthias's suggestion makes this practically impossible so -1 for mixed
> tabs/spaces from my side.
>
> Matthias J. Sax <[hidden email]> ezt írta (időpont: 2015. okt. 21., Sze,
> 11:46):
>
> > I actually like tabs a lot, however, in a "mixed" style together with
> > spaces. Example:
> >
> >         myVar.callMethod(param1, // many more
> >         .................paramX); // the dots mark space indention
> >
> > indenting "paramX" with tabs does not give nice aliment. Not sure if
> > this would be a feasible compromise to keeps tabs in general, but use
> > space for cases as above.
> >
> > If this in no feasible compromise, I would prefer space to get the
> > correct indention in examples as above. Even if this result in a
> > complete reformatting of the whole code.
> >
> >
> > Why this? Everybody can set this in it's IDE/editor as he/she wishes...
> >
> > >> If we keep tabs, we will have to specify the line length relative to a
> > tab
> > >> size (like 4).
> >
> >
> > -Matthias
> >
> >
> >
> >
> >
> > On 10/21/2015 11:06 AM, Ufuk Celebi wrote:
> > > To summarize up to this point:
> > >
> > > - All are in favour of Google check style (with the following possible
> > > exceptions)
> > > - Proposed exceptions so far:
> > >   * Specific line length 100 vs. 120 characters
> > >   * Keep tabs instead converting to spaces (this would translate to
> > > skipping/coming up with some indentation rules as well)
> > >
> > > If we keep tabs, we will have to specify the line length relative to a
> > tab
> > > size (like 4).
> > >
> > > Let’s keep the discussion going a little longer. I think it has
> proceeded
> > > in a very reasonable manner so far. Thanks for this!
> > >
> > > – Ufuk
> > >
> > > On Wed, Oct 21, 2015 at 10:29 AM, Fabian Hueske <[hidden email]>
> > wrote:
> > >
> > >> Thanks Max for checking the modifications by the Google code style.
> > >> It is very good to know, that the impact on the code base would not be
> > too
> > >> massive. If the Google code style would have touched almost every
> line,
> > I
> > >> would have been in favor of converting to spaces. However, your
> > assessment
> > >> is a strong argument to continue with tabs, IMO.
> > >>
> > >> Regarding the line length limit, I personally find 100 chars too
> narrow
> > but
> > >> would be +1 for having a limit.
> > >>
> > >> +1 for discussing the Scala style in a separate thread.
> > >>
> > >> Fabian
> > >>
> > >> 2015-10-20 18:12 GMT+02:00 Maximilian Michels <[hidden email]>:
> > >>
> > >>> I'm a little less excited about this. You might not be aware but, for
> > >>> a large portion of the source code, we already follow the 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 <
> > [hidden email]>
> > >>> wrote:
> > >>>> 1) yes. Been dancing this issue for a while. Let's pull the trigger.
> > >> Did
> > >>>> the exercise with Tachyon while back and did help readability and
> > >>>> homogeneity of code.
> > >>>>
> > >>>> 2) +1 for Google Java style with documented exceptions and
> explanation
> > >> on
> > >>>> why.
> > >>>>
> > >>>> On Tuesday, October 20, 2015, Ufuk Celebi <[hidden email]> wrote:
> > >>>>
> > >>>>> DISCLAIMER: This is not my personal idea, but a community
> discussion
> > >>> from
> > >>>>> some time ago. Don't kill the messenger.
> > >>>>>
> > >>>>> In March we were discussing issues with heterogeneity of the code
> > [1].
> > >>> The
> > >>>>> summary is that we had a consensus to enforce a stricter code style
> > on
> > >>> our
> > >>>>> Java code base in order to make it easier to switch between
> projects
> > >>> and to
> > >>>>> have clear rules for new contributions. The main proposal in the
> last
> > >>>>> discussion was to go with Google's Java code style. Not all were
> > fully
> > >>>>> satisfied with this, but still everyone agreed on some kind of
> style.
> > >>>>>
> > >>>>> I think the upcoming 0.10 release is a good point to finally go
> > >> through
> > >>>>> with these changes (right after the release/branch-off).
> > >>>>>
> > >>>>> I propose to go with Google's Java code style [2] as proposed
> > earlier.
> > >>>>>
> > >>>>> PROs:
> > >>>>> - Clear style guide available
> > >>>>> - Tooling like checkstyle rules, IDE plugins already available
> > >>>>>
> > >>>>> CONs:
> > >>>>> - Fully breaks our current style
> > >>>>>
> > >>>>> The main problem with this will be open pull requests, which will
> be
> > >>> harder
> > >>>>> to merge after all the changes. On the other hand, should pull
> > >> requests
> > >>>>> that have been open for a long time block this? Most of the
> important
> > >>>>> changes will be merged for the release anyways. I think in the long
> > >> run
> > >>> we
> > >>>>> will gain more than we loose by this (more homogenous code, clear
> > >>> rules).
> > >>>>> And it is questionable whether we will ever be able to do such a
> > >> change
> > >>> in
> > >>>>> the future if we cannot do it now. The project will most likely
> grow
> > >> and
> > >>>>> attract more contributors, at which point it will be even harder to
> > >> do.
> > >>>>>
> > >>>>> Please make sure to answer the following points in the discussion:
> > >>>>>
> > >>>>> 1) Are you (still) in favour of enforcing stricter rules on the
> Java
> > >>>>> codebase?
> > >>>>>
> > >>>>> 2) If yes, would you be OK with the Google's Java code style?
> > >>>>>
> > >>>>> – Ufuk
> > >>>>>
> > >>>>> [1]
> > >>>>>
> > >>>>>
> > >>>
> > >>
> >
> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e
> > >>>>>
> > >>>>> [2] https://google.github.io/styleguide/javaguide.html
> > >>>>>
> > >>>
> > >>
> > >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Matthias J. Sax-2
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 <[hidden email]> wrote:
>
>> I think the nice thing about a common codestyle is that everyone can set
>> the template in the IDE and use the formatting commands.
>>
>> Matthias's suggestion makes this practically impossible so -1 for mixed
>> tabs/spaces from my side.
>>
>> Matthias J. Sax <[hidden email]> ezt írta (időpont: 2015. okt. 21., Sze,
>> 11:46):
>>
>>> I actually like tabs a lot, however, in a "mixed" style together with
>>> spaces. Example:
>>>
>>>         myVar.callMethod(param1, // many more
>>>         .................paramX); // the dots mark space indention
>>>
>>> indenting "paramX" with tabs does not give nice aliment. Not sure if
>>> this would be a feasible compromise to keeps tabs in general, but use
>>> space for cases as above.
>>>
>>> If this in no feasible compromise, I would prefer space to get the
>>> correct indention in examples as above. Even if this result in a
>>> complete reformatting of the whole code.
>>>
>>>
>>> Why this? Everybody can set this in it's IDE/editor as he/she wishes...
>>>
>>>>> If we keep tabs, we will have to specify the line length relative to a
>>> tab
>>>>> size (like 4).
>>>
>>>
>>> -Matthias
>>>
>>>
>>>
>>>
>>>
>>> On 10/21/2015 11:06 AM, Ufuk Celebi wrote:
>>>> To summarize up to this point:
>>>>
>>>> - All are in favour of Google check style (with the following possible
>>>> exceptions)
>>>> - Proposed exceptions so far:
>>>>   * Specific line length 100 vs. 120 characters
>>>>   * Keep tabs instead converting to spaces (this would translate to
>>>> skipping/coming up with some indentation rules as well)
>>>>
>>>> If we keep tabs, we will have to specify the line length relative to a
>>> tab
>>>> size (like 4).
>>>>
>>>> Let’s keep the discussion going a little longer. I think it has
>> proceeded
>>>> in a very reasonable manner so far. Thanks for this!
>>>>
>>>> – Ufuk
>>>>
>>>> On Wed, Oct 21, 2015 at 10:29 AM, Fabian Hueske <[hidden email]>
>>> wrote:
>>>>
>>>>> Thanks Max for checking the modifications by the Google code style.
>>>>> It is very good to know, that the impact on the code base would not be
>>> too
>>>>> massive. If the Google code style would have touched almost every
>> line,
>>> I
>>>>> would have been in favor of converting to spaces. However, your
>>> assessment
>>>>> is a strong argument to continue with tabs, IMO.
>>>>>
>>>>> Regarding the line length limit, I personally find 100 chars too
>> narrow
>>> but
>>>>> would be +1 for having a limit.
>>>>>
>>>>> +1 for discussing the Scala style in a separate thread.
>>>>>
>>>>> Fabian
>>>>>
>>>>> 2015-10-20 18:12 GMT+02:00 Maximilian Michels <[hidden email]>:
>>>>>
>>>>>> I'm a little less excited about this. You might not be aware but, for
>>>>>> a large portion of the source code, we already follow the 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 <
>>> [hidden email]>
>>>>>> wrote:
>>>>>>> 1) yes. Been dancing this issue for a while. Let's pull the trigger.
>>>>> Did
>>>>>>> the exercise with Tachyon while back and did help readability and
>>>>>>> homogeneity of code.
>>>>>>>
>>>>>>> 2) +1 for Google Java style with documented exceptions and
>> explanation
>>>>> on
>>>>>>> why.
>>>>>>>
>>>>>>> On Tuesday, October 20, 2015, Ufuk Celebi <[hidden email]> wrote:
>>>>>>>
>>>>>>>> DISCLAIMER: This is not my personal idea, but a community
>> discussion
>>>>>> from
>>>>>>>> some time ago. Don't kill the messenger.
>>>>>>>>
>>>>>>>> In March we were discussing issues with heterogeneity of the code
>>> [1].
>>>>>> The
>>>>>>>> summary is that we had a consensus to enforce a stricter code style
>>> on
>>>>>> our
>>>>>>>> Java code base in order to make it easier to switch between
>> projects
>>>>>> and to
>>>>>>>> have clear rules for new contributions. The main proposal in the
>> last
>>>>>>>> discussion was to go with Google's Java code style. Not all were
>>> fully
>>>>>>>> satisfied with this, but still everyone agreed on some kind of
>> style.
>>>>>>>>
>>>>>>>> I think the upcoming 0.10 release is a good point to finally go
>>>>> through
>>>>>>>> with these changes (right after the release/branch-off).
>>>>>>>>
>>>>>>>> I propose to go with Google's Java code style [2] as proposed
>>> earlier.
>>>>>>>>
>>>>>>>> PROs:
>>>>>>>> - Clear style guide available
>>>>>>>> - Tooling like checkstyle rules, IDE plugins already available
>>>>>>>>
>>>>>>>> CONs:
>>>>>>>> - Fully breaks our current style
>>>>>>>>
>>>>>>>> The main problem with this will be open pull requests, which will
>> be
>>>>>> harder
>>>>>>>> to merge after all the changes. On the other hand, should pull
>>>>> requests
>>>>>>>> that have been open for a long time block this? Most of the
>> important
>>>>>>>> changes will be merged for the release anyways. I think in the long
>>>>> run
>>>>>> we
>>>>>>>> will gain more than we loose by this (more homogenous code, clear
>>>>>> rules).
>>>>>>>> And it is questionable whether we will ever be able to do such a
>>>>> change
>>>>>> in
>>>>>>>> the future if we cannot do it now. The project will most likely
>> grow
>>>>> and
>>>>>>>> attract more contributors, at which point it will be even harder to
>>>>> do.
>>>>>>>>
>>>>>>>> Please make sure to answer the following points in the discussion:
>>>>>>>>
>>>>>>>> 1) Are you (still) in favour of enforcing stricter rules on the
>> Java
>>>>>>>> codebase?
>>>>>>>>
>>>>>>>> 2) If yes, would you be OK with the Google's Java code style?
>>>>>>>>
>>>>>>>> – Ufuk
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e
>>>>>>>>
>>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

Fabian Hueske-2
Any ideas how to deal with the mandatory JavaDoc rule for existing code?
Just adding empty headers to make the checkstyle pass or start a serious
effort to add the missing docs?

2015-10-21 13:31 GMT+02:00 Matthias J. Sax <[hidden email]>:

> Agreed. That's the reason why I am in favor of using vanilla 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 <[hidden email]>
> wrote:
> >
> >> I think the nice thing about a common codestyle is that everyone can set
> >> the template in the IDE and use the formatting commands.
> >>
> >> Matthias's suggestion makes this practically impossible so -1 for mixed
> >> tabs/spaces from my side.
> >>
> >> Matthias J. Sax <[hidden email]> ezt írta (időpont: 2015. okt. 21.,
> Sze,
> >> 11:46):
> >>
> >>> I actually like tabs a lot, however, in a "mixed" style together with
> >>> spaces. Example:
> >>>
> >>>         myVar.callMethod(param1, // many more
> >>>         .................paramX); // the dots mark space indention
> >>>
> >>> indenting "paramX" with tabs does not give nice aliment. Not sure if
> >>> this would be a feasible compromise to keeps tabs in general, but use
> >>> space for cases as above.
> >>>
> >>> If this in no feasible compromise, I would prefer space to get the
> >>> correct indention in examples as above. Even if this result in a
> >>> complete reformatting of the whole code.
> >>>
> >>>
> >>> Why this? Everybody can set this in it's IDE/editor as he/she wishes...
> >>>
> >>>>> If we keep tabs, we will have to specify the line length relative to
> a
> >>> tab
> >>>>> size (like 4).
> >>>
> >>>
> >>> -Matthias
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 10/21/2015 11:06 AM, Ufuk Celebi wrote:
> >>>> To summarize up to this point:
> >>>>
> >>>> - All are in favour of Google check style (with the following possible
> >>>> exceptions)
> >>>> - Proposed exceptions so far:
> >>>>   * Specific line length 100 vs. 120 characters
> >>>>   * Keep tabs instead converting to spaces (this would translate to
> >>>> skipping/coming up with some indentation rules as well)
> >>>>
> >>>> If we keep tabs, we will have to specify the line length relative to a
> >>> tab
> >>>> size (like 4).
> >>>>
> >>>> Let’s keep the discussion going a little longer. I think it has
> >> proceeded
> >>>> in a very reasonable manner so far. Thanks for this!
> >>>>
> >>>> – Ufuk
> >>>>
> >>>> On Wed, Oct 21, 2015 at 10:29 AM, Fabian Hueske <[hidden email]>
> >>> wrote:
> >>>>
> >>>>> Thanks Max for checking the modifications by the Google code style.
> >>>>> It is very good to know, that the impact on the code base would not
> be
> >>> too
> >>>>> massive. If the Google code style would have touched almost every
> >> line,
> >>> I
> >>>>> would have been in favor of converting to spaces. However, your
> >>> assessment
> >>>>> is a strong argument to continue with tabs, IMO.
> >>>>>
> >>>>> Regarding the line length limit, I personally find 100 chars too
> >> narrow
> >>> but
> >>>>> would be +1 for having a limit.
> >>>>>
> >>>>> +1 for discussing the Scala style in a separate thread.
> >>>>>
> >>>>> Fabian
> >>>>>
> >>>>> 2015-10-20 18:12 GMT+02:00 Maximilian Michels <[hidden email]>:
> >>>>>
> >>>>>> I'm a little less excited about this. You might not be aware but,
> for
> >>>>>> a large portion of the source code, we already follow the 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 <
> >>> [hidden email]>
> >>>>>> wrote:
> >>>>>>> 1) yes. Been dancing this issue for a while. Let's pull the
> trigger.
> >>>>> Did
> >>>>>>> the exercise with Tachyon while back and did help readability and
> >>>>>>> homogeneity of code.
> >>>>>>>
> >>>>>>> 2) +1 for Google Java style with documented exceptions and
> >> explanation
> >>>>> on
> >>>>>>> why.
> >>>>>>>
> >>>>>>> On Tuesday, October 20, 2015, Ufuk Celebi <[hidden email]> wrote:
> >>>>>>>
> >>>>>>>> DISCLAIMER: This is not my personal idea, but a community
> >> discussion
> >>>>>> from
> >>>>>>>> some time ago. Don't kill the messenger.
> >>>>>>>>
> >>>>>>>> In March we were discussing issues with heterogeneity of the code
> >>> [1].
> >>>>>> The
> >>>>>>>> summary is that we had a consensus to enforce a stricter code
> style
> >>> on
> >>>>>> our
> >>>>>>>> Java code base in order to make it easier to switch between
> >> projects
> >>>>>> and to
> >>>>>>>> have clear rules for new contributions. The main proposal in the
> >> last
> >>>>>>>> discussion was to go with Google's Java code style. Not all were
> >>> fully
> >>>>>>>> satisfied with this, but still everyone agreed on some kind of
> >> style.
> >>>>>>>>
> >>>>>>>> I think the upcoming 0.10 release is a good point to finally go
> >>>>> through
> >>>>>>>> with these changes (right after the release/branch-off).
> >>>>>>>>
> >>>>>>>> I propose to go with Google's Java code style [2] as proposed
> >>> earlier.
> >>>>>>>>
> >>>>>>>> PROs:
> >>>>>>>> - Clear style guide available
> >>>>>>>> - Tooling like checkstyle rules, IDE plugins already available
> >>>>>>>>
> >>>>>>>> CONs:
> >>>>>>>> - Fully breaks our current style
> >>>>>>>>
> >>>>>>>> The main problem with this will be open pull requests, which will
> >> be
> >>>>>> harder
> >>>>>>>> to merge after all the changes. On the other hand, should pull
> >>>>> requests
> >>>>>>>> that have been open for a long time block this? Most of the
> >> important
> >>>>>>>> changes will be merged for the release anyways. I think in the
> long
> >>>>> run
> >>>>>> we
> >>>>>>>> will gain more than we loose by this (more homogenous code, clear
> >>>>>> rules).
> >>>>>>>> And it is questionable whether we will ever be able to do such a
> >>>>> change
> >>>>>> in
> >>>>>>>> the future if we cannot do it now. The project will most likely
> >> grow
> >>>>> and
> >>>>>>>> attract more contributors, at which point it will be even harder
> to
> >>>>> do.
> >>>>>>>>
> >>>>>>>> Please make sure to answer the following points in the discussion:
> >>>>>>>>
> >>>>>>>> 1) Are you (still) in favour of enforcing stricter rules on the
> >> Java
> >>>>>>>> codebase?
> >>>>>>>>
> >>>>>>>> 2) If yes, would you be OK with the Google's Java code style?
> >>>>>>>>
> >>>>>>>> – Ufuk
> >>>>>>>>
> >>>>>>>> [1]
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>
> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e
> >>>>>>>>
> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>
mxm
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Java code style

mxm
I think we have to document all these classes. Code Style doesn't come
for free :)

On Thu, Oct 22, 2015 at 3:09 PM, Fabian Hueske <[hidden email]> wrote:

> Any ideas how to deal with the mandatory JavaDoc rule for existing code?
> Just adding empty headers to make the checkstyle pass or start a serious
> effort to add the missing docs?
>
> 2015-10-21 13:31 GMT+02:00 Matthias J. Sax <[hidden email]>:
>
>> Agreed. That's the reason why I am in favor of using vanilla 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 <[hidden email]>
>> wrote:
>> >
>> >> I think the nice thing about a common codestyle is that everyone can set
>> >> the template in the IDE and use the formatting commands.
>> >>
>> >> Matthias's suggestion makes this practically impossible so -1 for mixed
>> >> tabs/spaces from my side.
>> >>
>> >> Matthias J. Sax <[hidden email]> ezt írta (időpont: 2015. okt. 21.,
>> Sze,
>> >> 11:46):
>> >>
>> >>> I actually like tabs a lot, however, in a "mixed" style together with
>> >>> spaces. Example:
>> >>>
>> >>>         myVar.callMethod(param1, // many more
>> >>>         .................paramX); // the dots mark space indention
>> >>>
>> >>> indenting "paramX" with tabs does not give nice aliment. Not sure if
>> >>> this would be a feasible compromise to keeps tabs in general, but use
>> >>> space for cases as above.
>> >>>
>> >>> If this in no feasible compromise, I would prefer space to get the
>> >>> correct indention in examples as above. Even if this result in a
>> >>> complete reformatting of the whole code.
>> >>>
>> >>>
>> >>> Why this? Everybody can set this in it's IDE/editor as he/she wishes...
>> >>>
>> >>>>> If we keep tabs, we will have to specify the line length relative to
>> a
>> >>> tab
>> >>>>> size (like 4).
>> >>>
>> >>>
>> >>> -Matthias
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On 10/21/2015 11:06 AM, Ufuk Celebi wrote:
>> >>>> To summarize up to this point:
>> >>>>
>> >>>> - All are in favour of Google check style (with the following possible
>> >>>> exceptions)
>> >>>> - Proposed exceptions so far:
>> >>>>   * Specific line length 100 vs. 120 characters
>> >>>>   * Keep tabs instead converting to spaces (this would translate to
>> >>>> skipping/coming up with some indentation rules as well)
>> >>>>
>> >>>> If we keep tabs, we will have to specify the line length relative to a
>> >>> tab
>> >>>> size (like 4).
>> >>>>
>> >>>> Let’s keep the discussion going a little longer. I think it has
>> >> proceeded
>> >>>> in a very reasonable manner so far. Thanks for this!
>> >>>>
>> >>>> – Ufuk
>> >>>>
>> >>>> On Wed, Oct 21, 2015 at 10:29 AM, Fabian Hueske <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>>> Thanks Max for checking the modifications by the Google code style.
>> >>>>> It is very good to know, that the impact on the code base would not
>> be
>> >>> too
>> >>>>> massive. If the Google code style would have touched almost every
>> >> line,
>> >>> I
>> >>>>> would have been in favor of converting to spaces. However, your
>> >>> assessment
>> >>>>> is a strong argument to continue with tabs, IMO.
>> >>>>>
>> >>>>> Regarding the line length limit, I personally find 100 chars too
>> >> narrow
>> >>> but
>> >>>>> would be +1 for having a limit.
>> >>>>>
>> >>>>> +1 for discussing the Scala style in a separate thread.
>> >>>>>
>> >>>>> Fabian
>> >>>>>
>> >>>>> 2015-10-20 18:12 GMT+02:00 Maximilian Michels <[hidden email]>:
>> >>>>>
>> >>>>>> I'm a little less excited about this. You might not be aware but,
>> for
>> >>>>>> a large portion of the source code, we already follow the 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 <
>> >>> [hidden email]>
>> >>>>>> wrote:
>> >>>>>>> 1) yes. Been dancing this issue for a while. Let's pull the
>> trigger.
>> >>>>> Did
>> >>>>>>> the exercise with Tachyon while back and did help readability and
>> >>>>>>> homogeneity of code.
>> >>>>>>>
>> >>>>>>> 2) +1 for Google Java style with documented exceptions and
>> >> explanation
>> >>>>> on
>> >>>>>>> why.
>> >>>>>>>
>> >>>>>>> On Tuesday, October 20, 2015, Ufuk Celebi <[hidden email]> wrote:
>> >>>>>>>
>> >>>>>>>> DISCLAIMER: This is not my personal idea, but a community
>> >> discussion
>> >>>>>> from
>> >>>>>>>> some time ago. Don't kill the messenger.
>> >>>>>>>>
>> >>>>>>>> In March we were discussing issues with heterogeneity of the code
>> >>> [1].
>> >>>>>> The
>> >>>>>>>> summary is that we had a consensus to enforce a stricter code
>> style
>> >>> on
>> >>>>>> our
>> >>>>>>>> Java code base in order to make it easier to switch between
>> >> projects
>> >>>>>> and to
>> >>>>>>>> have clear rules for new contributions. The main proposal in the
>> >> last
>> >>>>>>>> discussion was to go with Google's Java code style. Not all were
>> >>> fully
>> >>>>>>>> satisfied with this, but still everyone agreed on some kind of
>> >> style.
>> >>>>>>>>
>> >>>>>>>> I think the upcoming 0.10 release is a good point to finally go
>> >>>>> through
>> >>>>>>>> with these changes (right after the release/branch-off).
>> >>>>>>>>
>> >>>>>>>> I propose to go with Google's Java code style [2] as proposed
>> >>> earlier.
>> >>>>>>>>
>> >>>>>>>> PROs:
>> >>>>>>>> - Clear style guide available
>> >>>>>>>> - Tooling like checkstyle rules, IDE plugins already available
>> >>>>>>>>
>> >>>>>>>> CONs:
>> >>>>>>>> - Fully breaks our current style
>> >>>>>>>>
>> >>>>>>>> The main problem with this will be open pull requests, which will
>> >> be
>> >>>>>> harder
>> >>>>>>>> to merge after all the changes. On the other hand, should pull
>> >>>>> requests
>> >>>>>>>> that have been open for a long time block this? Most of the
>> >> important
>> >>>>>>>> changes will be merged for the release anyways. I think in the
>> long
>> >>>>> run
>> >>>>>> we
>> >>>>>>>> will gain more than we loose by this (more homogenous code, clear
>> >>>>>> rules).
>> >>>>>>>> And it is questionable whether we will ever be able to do such a
>> >>>>> change
>> >>>>>> in
>> >>>>>>>> the future if we cannot do it now. The project will most likely
>> >> grow
>> >>>>> and
>> >>>>>>>> attract more contributors, at which point it will be even harder
>> to
>> >>>>> do.
>> >>>>>>>>
>> >>>>>>>> Please make sure to answer the following points in the discussion:
>> >>>>>>>>
>> >>>>>>>> 1) Are you (still) in favour of enforcing stricter rules on the
>> >> Java
>> >>>>>>>> codebase?
>> >>>>>>>>
>> >>>>>>>> 2) If yes, would you be OK with the Google's Java code style?
>> >>>>>>>>
>> >>>>>>>> – Ufuk
>> >>>>>>>>
>> >>>>>>>> [1]
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>
>> >>>>>
>> >>>
>> >>
>> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@...%3e
>> >>>>>>>>
>> >>>>>>>> [2] https://google.github.io/styleguide/javaguide.html
>> >>>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>>
>>
123