flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ufuk Celebi <...@apache.org>
Subject Re: [DISCUSS] Java code style
Date Mon, 09 Nov 2015 13:02:15 GMT
Minor thing in favour of spaces: Reviewability on GitHub is improved (they use 8 spaces for
tabs and line length of 120, which often results in too long lines).

> On 09 Nov 2015, at 13:53, Fabian Hueske <fhueske@gmail.com> wrote:
> 
> I don't see other benefits except maybe being closer to the vanilla Google
> style.
> 
> 2015-11-02 20:46 GMT+01:00 Stephan Ewen <sewen@apache.org>:
> 
>> I think by now virtually everyone prefers spaces if it came for free, so it
>> is a matter of making an educated decision about the cost/benefit
>> tradeoffs.
>> 
>> What are the benefits of spaces in the style other than people liking the
>> looks of space-formatted code better (aesthetics, schmaesthetics ;-) )
>> 
>> 
>> On Mon, Nov 2, 2015 at 5:38 AM, Matthias J. Sax <mjsax@apache.org> wrote:
>> 
>>> Thanks for the summary Fabian.
>>> 
>>> Maybe we should have kind of a vote about this. No classical Apache vote
>>> though, but voting for different options (so only +1), and the option
>>> with the highest score wins? (Not sure if this is possible to do...)
>>> 
>>> About spaced vs. tabs:
>>>> "AFAIR, nobody said to have a personal preferences of tabs over
>> spaces."
>>> 
>>> I think this is wrong. If I am correct, Till and myself would prefer
>>> spaces (but non of us is super strict about this -- we could both live
>>> with tabs too).
>>> 
>>> -Matthias
>>> 
>>> On 11/02/2015 12:14 PM, Fabian Hueske wrote:
>>>> OK, I'll try to summarize the discussion so far (please correct me if I
>>> got
>>>> something wrong):
>>>> 
>>>> Everybody is in favor of adding a stricter code style based on the
>> Google
>>>> Java code style.
>>>> Main points of discussion are:
>>>> 1) Line length
>>>> 2) JavaDocs
>>>> 3) Tabs vs. Spaces
>>>> 
>>>> -- Line length
>>>> Issue:
>>>> Google code style demands 80 or 100 chars line length limit.
>>>> Some people find this too narrow.
>>>> 
>>>> Discussion so far:
>>>> Nobody objected against a limit of 120 chars, AFAIR.
>>>> 
>>>> -- JavaDocs
>>>> Issue:
>>>> Google code style says "At the *minimum*, Javadoc is present for every
>>>> public class, and every public or protected member of such a class,
>> with
>>> a
>>>> few exceptions noted below." Exceptions are self-explanatory methods
>> like
>>>> getters and setters and overwritten method.
>>>> Significant parts of the Flink code base do not comply with this
>>>> requirement. It would be a huge effort to add the corresponding code
>>>> documentation.
>>>> 
>>>> Discussion so far:
>>>> Disable JavaDoc checks when adding the code style and opening JIRAs for
>>>> adding JavaDocs on a per Maven module level (with potentially
>> subissues)
>>>> with target dates. Once a module complies to the rule, the JavaDoc
>> check
>>> is
>>>> enabled in the checkstyle.
>>>> 
>>>> -- Tabs vs. Spaces
>>>> Issue:
>>>> The Google code style requires two spaces for indention. The Java code
>>> base
>>>> of Flink uses tabs. Moving from tabs to spaces would touch every line
>> of
>>>> Java code and therefore might make the tracking of changes in the past
>>> much
>>>> harder.
>>>> Max provided some numbers for applying the Google code style on the
>>> current
>>>> code base: The style checker found 28k violations (possibly multiple
>> ones
>>>> per LOC) on 121k LOC of Java code in 1601 out of 3251 Java classes. So
>>>> Google code style without spaces would touch every second file and
>> about
>>>> every 4th line of code. The question I have, would it be easier to
>> track
>>>> history with a commit that touches 1/2 (or 1/4) of the code base
>> compared
>>>> to one that touches everything.
>>>> 
>>>> Discussion so far:
>>>> AFAIR, nobody said to have a personal preferences of tabs over spaces.
>>>> However, some people raised concerns that the implied changes of moving
>>> the
>>>> code base from tabs to spaces would be too massive and the "benefits"
>>> would
>>>> not justify the "cost" of the change.
>>>> I think, this is the main point of discussion, right now.
>>>> 
>>>> If we want to come to a conclusion, we should not let this discussion
>>> fall
>>>> asleep (as happened a few times in the past).
>>>> 
>>>> Does anybody NOT agree with the "solutions" for line length and
>> JavaDocs,
>>>> i.e., 120 chars and "lazy" adding of JavaDocs with JIRA tracking, or
>> has
>>>> another proposal?
>>>> How can we resolve the Tabs vs. Spaces discussion?
>>>> 
>>>> Cheers, Fabian
>>>> 
>>>> 
>>>> 
>>>> 2015-10-30 18:16 GMT+01:00 Maximilian Michels <mxm@apache.org>:
>>>> 
>>>>> I looked up if the Checkstyle plugin would also support tabs with a
>>>>> fixed line length. Indeed, this is possible because a tab can be
>>>>> mapped to a fixed number of spaces.
>>>>> 
>>>>> I've modified the default Google Style Checkstyle file. I changed the
>>>>> indention to tabs (2 spaces) and increased the line length to 120:
>>>>> https://gist.github.com/mxm/2ca4ef7702667c167d10
>>>>> 
>>>>> The scan of the entire Flink project resulted in 27,992 items in 1601
>>>>> files. This is roughly corresponds to the number of lines we would
>>>>> have to touch to comply with the style rules. Note that, one line may
>>>>> contain multiple items. A lot of the items are import statements.
>>>>> 
>>>>> Next, I tried running the vanilla Google Style Checkstyle file over
>>>>> the entire code base but my IntelliJ crashed. Using Maven, I wasn't
>>>>> able to get a total result displayed but I'm assuming it would be
>>>>> almost all lines of Flink code that had a violation due to tabs.
>>>>> 
>>>>> On Mon, Oct 26, 2015 at 6:56 PM, Suneel Marthi <
>> suneel.marthi@gmail.com
>>>> 
>>>>> wrote:
>>>>>> 2 spaces is the convention that's followed on Mahout and Oryx.
>>>>>> 
>>>>>> On Mon, Oct 26, 2015 at 1:42 PM, Till Rohrmann <trohrmann@apache.org
>>> 
>>>>> wrote:
>>>>>> 
>>>>>>> Concerning question 2 Tabs vs. Spaces, in case of spaces we would
>> have
>>>>> to
>>>>>>> decide on the number of spaces, too. The Google Java style says
to
>> use
>>>>> a 2
>>>>>>> space indentation, which is in my opinion sufficient to distinguish
>>>>>>> different indentations levels from each other. Furthermore, it
would
>>>>> save
>>>>>>> some space.
>>>>>>> 
>>>>>>> I would not vote -1 if we keep tabs.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Sat, Oct 24, 2015 at 8:33 PM, Henry Saputra <
>>> henry.saputra@gmail.com
>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> +1 for adding restriction for Javadoc at least at the header
of
>>> public
>>>>>>>> classes and methods.
>>>>>>>> 
>>>>>>>> We did the exercise in Twill and seemed to work pretty well.
>>>>>>>> 
>>>>>>>> On Fri, Oct 23, 2015 at 1:34 AM, Maximilian Michels <
>> mxm@apache.org>
>>>>>>>> wrote:
>>>>>>>>> I don't think lazily adding comments will work. However,
I'm fine
>>>>> with
>>>>>>>>> adding all the checkstyle rules one module at a time
(with a jira
>>>>>>>>> issue to keep track of the modules already converted).
It's not
>>>>> going
>>>>>>>>> to happen that we lazily add comments because that's
the reason
>> why
>>>>>>>>> comments are missing in the first place...
>>>>>>>>> 
>>>>>>>>> On Fri, Oct 23, 2015 at 12:05 AM, Henry Saputra <
>>>>>>> henry.saputra@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>> Could we make certain rules to give warning instead
of error?
>>>>>>>>>> 
>>>>>>>>>> This would allow us to cherry-pick certain rules
we would like
>>>>> people
>>>>>>>>>> to follow but not strictly enforced.
>>>>>>>>>> 
>>>>>>>>>> - Henry
>>>>>>>>>> 
>>>>>>>>>> On Thu, Oct 22, 2015 at 9:20 AM, Stephan Ewen <sewen@apache.org>
>>>>>>> wrote:
>>>>>>>>>>> I don't think a "let add comments to everything"
effort gives us
>>>>> good
>>>>>>>>>>> comments, actually. It just gives us checkmark
comments that
>> make
>>>>> the
>>>>>>>> rules
>>>>>>>>>>> pass.
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Oct 22, 2015 at 3:29 PM, Fabian Hueske
<
>> fhueske@gmail.com
>>>>>> 
>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Sure, I don't expect it to be free.
>>>>>>>>>>>> But everybody should be aware of the cost
of adding this code
>>>>> style,
>>>>>>>> i.e.,
>>>>>>>>>>>> spending a huge amount of time on reformatting
and documenting
>>>>> code.
>>>>>>>>>>>> 
>>>>>>>>>>>> Alternatively, we could drop the JavaDocs
rule and make the
>>>>>>> transition
>>>>>>>>>>>> significantly cheaper.
>>>>>>>>>>>> 
>>>>>>>>>>>> 2015-10-22 15:24 GMT+02:00 Till Rohrmann
<trohrmann@apache.org
>>> :
>>>>>>>>>>>> 
>>>>>>>>>>>>> There ain’t no such thing as a free
lunch and code style.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Thu, Oct 22, 2015 at 3:13 PM, Maximilian
Michels <
>>>>>>> mxm@apache.org
>>>>>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I think we have to document all these
classes. Code Style
>>>>>>> doesn't
>>>>>>>> come
>>>>>>>>>>>>>> for free :)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Thu, Oct 22, 2015 at 3:09 PM,
Fabian Hueske <
>>>>>>> fhueske@gmail.com
>>>>>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Any ideas how to deal with the
mandatory JavaDoc rule for
>>>>>>>> existing
>>>>>>>>>>>>> code?
>>>>>>>>>>>>>>> Just adding empty headers to
make the checkstyle pass or
>>>>>>> start a
>>>>>>>>>>>>> serious
>>>>>>>>>>>>>>> effort to add the missing docs?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 2015-10-21 13:31 GMT+02:00 Matthias
J. Sax <
>>>>> mjsax@apache.org
>>>>>>>> :
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Agreed. That's the reason
why I am in favor of using
>>>>> vanilla
>>>>>>>> Google
>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>> style.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 10/21/2015 12:31 PM, Stephan
Ewen wrote:
>>>>>>>>>>>>>>>>> We started out originally
with mixed tab/spaces, but it
>>>>>>>> ended up
>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> people mixing spaces
and tabs arbitrarily, and there is
>>>>>>>> little way
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> enforce Matthias' specific
suggestion via checkstyle.
>>>>>>>>>>>>>>>>> That's why we dropped
spaces alltogether...
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Wed, Oct 21, 2015
at 12:03 PM, Gyula Fóra <
>>>>>>>>>>>> gyula.fora@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I think the nice
thing about a common codestyle is that
>>>>>>>> everyone
>>>>>>>>>>>>> can
>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>>>> the template in the
IDE and use the formatting
>>>>> commands.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Matthias's suggestion
makes this practically
>>>>> impossible so
>>>>>>>> -1 for
>>>>>>>>>>>>>> mixed
>>>>>>>>>>>>>>>>>> tabs/spaces from
my side.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Matthias J. Sax <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