flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias J. Sax" <mj...@apache.org>
Subject Re: [DISCUSS] Java code style
Date Fri, 23 Oct 2015 12:47:12 GMT
Yes. I think that's a good compromise. Additionally, I vote for a
"deadline" (or "target date") to get those JIRAs done (even if we cannot
enforce it) to not get "trapped" by the lazy approach.

On 10/23/2015 02:12 PM, Fabian Hueske wrote:
> Which basically defaults back to lazily adding JavaDocs (with some
> bookkeeping).
> 
> I'd be +1 for that.
> 
> 2015-10-23 14:09 GMT+02:00 Matthias J. Sax <mjsax@apache.org>:
> 
>> A "deadline" is not really forcible.
>>
>> However, if we have a JIRA for each module, we can enable JavaDoc
>> enforcement when the JIRA is resolved. And we should discuss the
>> progress about those tickets regularly (to hopefully find volunteers to
>> resolve them) and use a special tag for them.
>>
>> On 10/23/2015 01:59 PM, Fabian Hueske wrote:
>>> And who should be "forced" to write the docs before the deadline passes?
>>> That's not going to work either, IMO.
>>>
>>> 2015-10-23 13:13 GMT+02:00 Matthias J. Sax <mjsax@apache.org>:
>>>
>>>> I don't care about line length.
>>>>
>>>> Still prefer whitespaces because it gives aligned indention for line
>>>> break in method calls (remember my example) But I would not vote -1 for
>>>> keeping tabs either.
>>>>
>>>> About JavaDocs: I agree with Max that lazy adding will not fix the
>>>> problem. There should be some enforcement (maybe module by module over
>>>> time; backed up with JIRAs; and maybe a fixed date when the JavaDocs
>>>> must be completed)
>>>>
>>>> -Matthias
>>>>
>>>>
>>>> On 10/23/2015 11:55 AM, Stephan Ewen wrote:
>>>>> I am with Vasia.
>>>>>
>>>>> Are spaces so important that we want to effectively wipe out the entire
>>>>> commit history?
>>>>>
>>>>> On Fri, Oct 23, 2015 at 11:51 AM, Vasiliki Kalavri <
>>>>> vasilikikalavri@gmail.com> wrote:
>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> sorry I haven't replied so far. I was enjoying the thread tough :P
>>>>>>
>>>>>> I'm +1 for 120 line length and tabs. I wouldn't voice a -1 for spaces,
>>>> but
>>>>>> it seems to me like an unnecessary change that would touch every
>> single
>>>>>> Java file and without substantially improving anything.
>>>>>>
>>>>>> JavaDocs by-module with JIRAs to track progress seems like the best
>>>> choice
>>>>>> to me.
>>>>>>
>>>>>> -Vasia.
>>>>>>
>>>>>> On 23 October 2015 at 11:34, Fabian Hueske <fhueske@gmail.com>
wrote:
>>>>>>
>>>>>>> Enforcing JavaDocs (no, by-file, by-module, global) is another
open
>>>>>>> question.
>>>>>>>
>>>>>>> Regarding the line length, I am OK with 120 chars.
>>>>>>>
>>>>>>> 2015-10-23 11:29 GMT+02:00 Ufuk Celebi <uce@apache.org>:
>>>>>>>
>>>>>>>> I think that we have two open questions now:
>>>>>>>>
>>>>>>>> 1. Line length
>>>>>>>>
>>>>>>>> From the discussion so far, I think that no one wants 80
characters
>>>>>> line
>>>>>>>> length.
>>>>>>>>
>>>>>>>> The final decision will be 100 vs. 120 characters. 120 characters
is
>>>>>> what
>>>>>>>> we have right now (for most parts), so it is fair to keep
it that
>> way,
>>>>>>> but
>>>>>>>> enforce it (get rid of the longer lines).
>>>>>>>>
>>>>>>>> Is everyone OK with this?
>>>>>>>>
>>>>>>>> 2. Tabs vs. Spaces:
>>>>>>>>
>>>>>>>> I hope I’m not misrepresenting someone with the following
summary of
>>>>>>>> positions.
>>>>>>>>
>>>>>>>> Tabs:
>>>>>>>> - Robert
>>>>>>>> - Max
>>>>>>>> - Fabian
>>>>>>>> (- Stephan)
>>>>>>>>
>>>>>>>> Spaces:
>>>>>>>> - Matthias
>>>>>>>> - Marton
>>>>>>>> - Till
>>>>>>>> - Gyula
>>>>>>>> - Henry
>>>>>>>> (- Stephan)
>>>>>>>>
>>>>>>>> Let’s wrap the discussion up by focusing on this question.
>>>>>>>>
>>>>>>>> What are the PROs/CONs for the respective approaches? If
we went
>> with
>>>>>> the
>>>>>>>> opposing approach, would you voice a -1? E.g. would a “tabs
person"
>> -1
>>>>>> a
>>>>>>>> "spaces decision" and vice versa?
>>>>>>>>
>>>>>>>> – Ufuk
>>>>>>>>
>>>>>>>>> On 23 Oct 2015, at 10:34, Maximilian Michels <mxm@apache.org>
>> wrote:
>>>>>>>>>
>>>>>>>>> I don't think lazily adding comments will work. However,
I'm fine
>>>>>> with
>>>>>>>>> adding all the checkstyle rules one module at a time
(with a jira
>>>>>>>>> issue to keep track of the modules already converted).
It's not
>> going
>>>>>>>>> to happen that we lazily add comments because that's
the reason why
>>>>>>>>> comments are missing in the first place...
>>>>>>>>>
>>>>>>>>> On Fri, Oct 23, 2015 at 12:05 AM, Henry Saputra <
>>>>>>> henry.saputra@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>> Could we make certain rules to give warning instead
of error?
>>>>>>>>>>
>>>>>>>>>> This would allow us to cherry-pick certain rules
we would like
>>>>>> people
>>>>>>>>>> to follow but not strictly enforced.
>>>>>>>>>>
>>>>>>>>>> - Henry
>>>>>>>>>>
>>>>>>>>>> On Thu, Oct 22, 2015 at 9:20 AM, Stephan Ewen <sewen@apache.org>
>>>>>>> wrote:
>>>>>>>>>>> I don't think a "let add comments to everything"
effort gives us
>>>>>> good
>>>>>>>>>>> comments, actually. It just gives us checkmark
comments that make
>>>>>> the
>>>>>>>> rules
>>>>>>>>>>> pass.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 22, 2015 at 3:29 PM, Fabian Hueske
<
>> fhueske@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Sure, I don't expect it to be free.
>>>>>>>>>>>> But everybody should be aware of the cost
of adding this code
>>>>>> style,
>>>>>>>> i.e.,
>>>>>>>>>>>> spending a huge amount of time on reformatting
and documenting
>>>>>> code.
>>>>>>>>>>>>
>>>>>>>>>>>> Alternatively, we could drop the JavaDocs
rule and make the
>>>>>>> transition
>>>>>>>>>>>> significantly cheaper.
>>>>>>>>>>>>
>>>>>>>>>>>> 2015-10-22 15:24 GMT+02:00 Till Rohrmann
<trohrmann@apache.org
>>> :
>>>>>>>>>>>>
>>>>>>>>>>>>> There ain’t no such thing as a free
lunch and code style.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Oct 22, 2015 at 3:13 PM, Maximilian
Michels <
>>>>>>> mxm@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think we have to document all these
classes. Code Style
>>>>>> doesn't
>>>>>>>> come
>>>>>>>>>>>>>> for free :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Oct 22, 2015 at 3:09 PM,
Fabian Hueske <
>>>>>> fhueske@gmail.com
>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Any ideas how to deal with the
mandatory JavaDoc rule for
>>>>>>> existing
>>>>>>>>>>>>> code?
>>>>>>>>>>>>>>> Just adding empty headers to
make the checkstyle pass or
>> start
>>>>>> a
>>>>>>>>>>>>> serious
>>>>>>>>>>>>>>> effort to add the missing docs?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2015-10-21 13:31 GMT+02:00 Matthias
J. Sax <mjsax@apache.org
>>> :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Agreed. That's the reason
why I am in favor of using vanilla
>>>>>>>> Google
>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>> style.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10/21/2015 12:31 PM, Stephan
Ewen wrote:
>>>>>>>>>>>>>>>>> We started out originally
with mixed tab/spaces, but it
>> ended
>>>>>>> up
>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> people mixing spaces
and tabs arbitrarily, and there is
>>>>>> little
>>>>>>>> way
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> enforce Matthias' specific
suggestion via checkstyle.
>>>>>>>>>>>>>>>>> That's why we dropped
spaces alltogether...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, Oct 21, 2015
at 12:03 PM, Gyula Fóra <
>>>>>>>>>>>> gyula.fora@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think the nice
thing about a common codestyle is that
>>>>>>> everyone
>>>>>>>>>>>>> can
>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>>>> the template in the
IDE and use the formatting commands.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Matthias's suggestion
makes this practically impossible so
>>>>>> -1
>>>>>>>> for
>>>>>>>>>>>>>> mixed
>>>>>>>>>>>>>>>>>> tabs/spaces from
my side.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Matthias J. Sax <mjsax@apache.org>
ezt írta (időpont:
>> 2015.
>>>>>>>> okt.
>>>>>>>>>>>>>> 21.,
>>>>>>>>>>>>>>>> Sze,
>>>>>>>>>>>>>>>>>> 11:46):
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I actually like
tabs a lot, however, in a "mixed" style
>>>>>>>> together
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>> spaces. Example:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>        myVar.callMethod(param1,
// many more
>>>>>>>>>>>>>>>>>>>        .................paramX);
// the dots mark space
>>>>>>>>>>>> indention
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> indenting "paramX"
with tabs does not give nice aliment.
>>>>>> Not
>>>>>>>>>>>> sure
>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>> this would be
a feasible compromise to keeps tabs in
>>>>>> general,
>>>>>>>>>>>> but
>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>> space for cases
as above.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If this in no
feasible compromise, I would prefer space
>> to
>>>>>>> get
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> correct indention
in examples as above. Even if this
>> result
>>>>>>> in
>>>>>>>> a
>>>>>>>>>>>>>>>>>>> complete reformatting
of the whole code.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why this? Everybody
can set this in it's IDE/editor as
>>>>>> he/she
>>>>>>>>>>>>>> wishes...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If we
keep tabs, we will have to specify the line
>> length
>>>>>>>>>>>>> relative
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>> tab
>>>>>>>>>>>>>>>>>>>>> size
(like 4).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -Matthias
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 10/21/2015
11:06 AM, Ufuk Celebi wrote:
>>>>>>>>>>>>>>>>>>>> To summarize
up to this point:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> - All are
in favour of Google check style (with the
>>>>>>> following
>>>>>>>>>>>>>> possible
>>>>>>>>>>>>>>>>>>>> exceptions)
>>>>>>>>>>>>>>>>>>>> - Proposed
exceptions so far:
>>>>>>>>>>>>>>>>>>>>  * Specific
line length 100 vs. 120 characters
>>>>>>>>>>>>>>>>>>>>  * Keep tabs
instead converting to spaces (this would
>>>>>>>>>>>> translate
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> skipping/coming
up with some indentation rules as well)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If we keep
tabs, we will have to specify the line length
>>>>>>>>>>>> relative
>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>>>>>>> tab
>>>>>>>>>>>>>>>>>>>> size (like
4).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Let’s keep
the discussion going a little longer. I think
>>>>>> it
>>>>>>>> has
>>>>>>>>>>>>>>>>>> proceeded
>>>>>>>>>>>>>>>>>>>> in a very
reasonable manner so far. Thanks for this!
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> – Ufuk
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Wed, Oct
21, 2015 at 10:29 AM, Fabian Hueske <
>>>>>>>>>>>>> fhueske@gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks
Max for checking the modifications by the Google
>>>>>>> code
>>>>>>>>>>>>>> style.
>>>>>>>>>>>>>>>>>>>>> It is
very good to know, that the impact on the code
>> base
>>>>>>>>>>>> would
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>>> massive.
If the Google code style would have touched
>>>>>> almost
>>>>>>>>>>>>> every
>>>>>>>>>>>>>>>>>> line,
>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>> would
have been in favor of converting to spaces.
>>>>>> However,
>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>> assessment
>>>>>>>>>>>>>>>>>>>>> is a
strong argument to continue with tabs, IMO.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Regarding
the line length limit, I personally find 100
>>>>>>> chars
>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>> narrow
>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>> would
be +1 for having a limit.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> +1 for
discussing the Scala style in a separate thread.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Fabian
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2015-10-20
18:12 GMT+02:00 Maximilian Michels <
>>>>>>>> mxm@apache.org
>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I'm
a little less excited about this. You might not be
>>>>>>> aware
>>>>>>>>>>>>> but,
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>> a
large portion of the source code, we already follow
>>>>>> the
>>>>>>>>>>>>> Google
>>>>>>>>>>>>>>>>>> style
>>>>>>>>>>>>>>>>>>>>>> guide.
The main changes will be tabs->spaces and
>> 80/100
>>>>>>>>>>>>>> characters
>>>>>>>>>>>>>>>>>>>>>> line
limit.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Out
of curiosity, I ran the official Google Style
>>>>>>> Checkstyle
>>>>>>>>>>>>>>>>>>>>>> configuration
to confirm my suspicion:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml
>>>>>>>>>>>>>>>>>>>>>> The
changes are very little if we turn off line length
>>>>>>> limit
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> tabs-to-spaces
conversion.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> There
are some things I really like about the Google
>>>>>>> style,
>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>>>>>>>>> class
has to have a JavaDoc and spaces after keywords
>>>>>>> (can't
>>>>>>>>>>>>>> stand
>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>> there
aren't any). I'm not sure if we should change
>> tabs
>>>>>>> to
>>>>>>>>>>>>>> spaces,
>>>>>>>>>>>>>>>>>>>>>> because
it means touching almost every single line of
>>>>>>> code.
>>>>>>>>>>>>>> However,
>>>>>>>>>>>>>>>>>>>>>> if
we keep the tabs, we cannot make use of the
>> different
>>>>>>>>>>>>>> indention
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>> case
statements or wrapped lines...maybe that's a
>>>>>>> compromise
>>>>>>>>>>>> we
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>> live
with.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If
we introduce the Google Style for Java, will we
>> also
>>>>>>>>>>>> impose
>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>> stricter
style check for Scala? IMHO the line length
>> is
>>>>>>> the
>>>>>>>>>>>>>>>> strictest
>>>>>>>>>>>>>>>>>>>>>> part
of the Scala Checkstyle.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On
Tue, Oct 20, 2015 at 4:14 PM, Henry Saputra <
>>>>>>>>>>>>>>>>>>> henry.saputra@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
1) yes. Been dancing this issue for a while. Let's
>> pull
>>>>>>> the
>>>>>>>>>>>>>>>> trigger.
>>>>>>>>>>>>>>>>>>>>> Did
>>>>>>>>>>>>>>>>>>>>>>>
the exercise with Tachyon while back and did help
>>>>>>>>>>>> readability
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>
homogeneity of code.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
2) +1 for Google Java style with documented
>> exceptions
>>>>>>> and
>>>>>>>>>>>>>>>>>> explanation
>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>
why.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
On Tuesday, October 20, 2015, Ufuk Celebi <
>>>>>>> uce@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
DISCLAIMER: This is not my personal idea, but a
>>>>>>> community
>>>>>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>>>>>>
some time ago. Don't kill the messenger.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
In March we were discussing issues with
>> heterogeneity
>>>>>> of
>>>>>>>>>>>> the
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>>>>>
summary is that we had a consensus to enforce a
>>>>>> stricter
>>>>>>>>>>>> code
>>>>>>>>>>>>>>>> style
>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>>>>>>>>>>
Java code base in order to make it easier to switch
>>>>>>>> between
>>>>>>>>>>>>>>>>>> projects
>>>>>>>>>>>>>>>>>>>>>> and
to
>>>>>>>>>>>>>>>>>>>>>>>>
have clear rules for new contributions. The main
>>>>>>> proposal
>>>>>>>>>>>> in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> last
>>>>>>>>>>>>>>>>>>>>>>>>
discussion was to go with Google's Java code style.
>>>>>> Not
>>>>>>>> all
>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>>>> fully
>>>>>>>>>>>>>>>>>>>>>>>>
satisfied with this, but still everyone agreed on
>> some
>>>>>>>> kind
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> style.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
I think the upcoming 0.10 release is a good point to
>>>>>>>>>>>> finally
>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>>>> through
>>>>>>>>>>>>>>>>>>>>>>>>
with these changes (right after the
>>>>>> release/branch-off).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
I propose to go with Google's Java code style [2] as
>>>>>>>>>>>> proposed
>>>>>>>>>>>>>>>>>>> earlier.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
PROs:
>>>>>>>>>>>>>>>>>>>>>>>>
- Clear style guide available
>>>>>>>>>>>>>>>>>>>>>>>>
- Tooling like checkstyle rules, IDE plugins already
>>>>>>>>>>>>> available
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
CONs:
>>>>>>>>>>>>>>>>>>>>>>>>
- Fully breaks our current style
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
The main problem with this will be open pull
>> requests,
>>>>>>>>>>>> which
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> harder
>>>>>>>>>>>>>>>>>>>>>>>>
to merge after all the changes. On the other hand,
>>>>>>> should
>>>>>>>>>>>>> pull
>>>>>>>>>>>>>>>>>>>>> requests
>>>>>>>>>>>>>>>>>>>>>>>>
that have been open for a long time block this? Most
>>>>>> of
>>>>>>>> the
>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>>>>
changes will be merged for the release anyways. I
>>>>>> think
>>>>>>> in
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>>>>>> run
>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>
will gain more than we loose by this (more
>> homogenous
>>>>>>>> code,
>>>>>>>>>>>>>> clear
>>>>>>>>>>>>>>>>>>>>>> rules).
>>>>>>>>>>>>>>>>>>>>>>>>
And it is questionable whether we will ever be able
>> to
>>>>>>> do
>>>>>>>>>>>>> such
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>
the future if we cannot do it now. The project will
>>>>>> most
>>>>>>>>>>>>> likely
>>>>>>>>>>>>>>>>>> grow
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>
attract more contributors, at which point it will be
>>>>>>> even
>>>>>>>>>>>>>> harder
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> do.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
Please make sure to answer the following points in
>> the
>>>>>>>>>>>>>> discussion:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
1) Are you (still) in favour of enforcing stricter
>>>>>> rules
>>>>>>>> on
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>>>>>>>>>>>>
codebase?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
2) If yes, would you be OK with the Google's Java
>> code
>>>>>>>>>>>> style?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
– Ufuk
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
[1]
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3cCANC1h_voN0B5omNWZxcHTyzwHAKeGhbZVQUyK7S9o2A36b891Q@mail.gmail.com%3e
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
[2]
>>>>>> https://google.github.io/styleguide/javaguide.html
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


Mime
View raw message