Jing Ge created FLINK-32546:
---
Summary: update Code Style Guide with Java properties naming
convention
Key: FLINK-32546
URL: https://issues.apache.org/jira/browse/FLINK-32546
Project: Flink
Issue
wuqingzhi created FLINK-28603:
-
Summary: Flink runtime.rpc.RpcServiceUtils code style
Key: FLINK-28603
URL: https://issues.apache.org/jira/browse/FLINK-28603
Project: Flink
Issue Type
Chesnay Schepler created FLINK-25059:
Summary: Update code style guide to encourage usage of AssertJ
Key: FLINK-25059
URL: https://issues.apache.org/jira/browse/FLINK-25059
Project: Flink
Matthias created FLINK-22695:
Summary: Update Flink's Code Style and Quality Guide to match the
Google Java Format style introduced
Key: FLINK-22695
URL: https://issues.apache.org/jira/browse/FLINK-
Huang Xingbo created FLINK-20793:
Summary: Fix NamesTest due to code style refactor
Key: FLINK-20793
URL: https://issues.apache.org/jira/browse/FLINK-20793
Project: Flink
Issue Type: Bug
Shengkai Fang created FLINK-20760:
-
Summary: Broken doc link in Apache Flink Code Style and Quality
Guide
Key: FLINK-20760
URL: https://issues.apache.org/jira/browse/FLINK-20760
Project: Flink
if not all suggestions in the code style
guidelines, there are good reasons supporting the suggestions (e.g., there
might be bad consequences not following the suggestions).
For this case, I think neither of the 2 approaches does any serious harm.
It's more about personal preference. I don't
t; through the private constructor. Seldom utility classes leverage the
> > >> enum mechanism. From my perspective, leveraging enum mechanism is more
> > >> simple and it can also overcome reflection.
> > >>
> > >> Whether using enum classes or private constructors, it will be good to
> > >> align the approach to achieve singleton in the whole Flink project.
> > >>
> > >> I would propose to leverage the enum mechanism in the Flink to
> > >> implement singleton pattern and append it to the code-style
> > >> guidelines. We may also have a JIRA ticket to refactor the existing
> > >> code.
> > >>
> > >> What do you think?
> > >>
> > >> [1] https://github.com/apache/flink/pull/13416
> > >>
> > >> Best,
> > >> Yangze Guo
> > >>
> > >
> >
> >
>
> --
> Best, Jingsong Lee
and it can also overcome reflection.
> >>
> >> Whether using enum classes or private constructors, it will be good to
> >> align the approach to achieve singleton in the whole Flink project.
> >>
> >> I would propose to leverage the enum mechanism in the Flink to
> >> implement singleton pattern and append it to the code-style
> >> guidelines. We may also have a JIRA ticket to refactor the existing
> >> code.
> >>
> >> What do you think?
> >>
> >> [1] https://github.com/apache/flink/pull/13416
> >>
> >> Best,
> >> Yangze Guo
> >>
> >
>
>
--
Best, Jingsong Lee
>>> through the private constructor. Seldom utility classes leverage the
>>>> enum mechanism. From my perspective, leveraging enum mechanism is more
>>>> simple and it can also overcome reflection.
>>>>
>>>> Whether using enum classes or p
pattern
> >> through the private constructor. Seldom utility classes leverage the
> >> enum mechanism. From my perspective, leveraging enum mechanism is more
> >> simple and it can also overcome reflection.
> >>
> >> Whether using enum classes or private construc
sses or private constructors, it will be good to
align the approach to achieve singleton in the whole Flink project.
I would propose to leverage the enum mechanism in the Flink to
implement singleton pattern and append it to the code-style
guidelines. We may also have a JIRA ticket to refactor th
num mechanism is more
> simple and it can also overcome reflection.
>
> Whether using enum classes or private constructors, it will be good to
> align the approach to achieve singleton in the whole Flink project.
>
> I would propose to leverage the enum mechanism in the Flink to
>
pattern and append it to the code-style
guidelines. We may also have a JIRA ticket to refactor the existing
code.
What do you think?
[1] https://github.com/apache/flink/pull/13416
Best,
Yangze Guo
klion26 commented on a change in pull request #245:
URL: https://github.com/apache/flink-web/pull/245#discussion_r417948740
##
File path: contributing/code-style-and-quality-preamble.zh.md
##
@@ -1,25 +1,25 @@
---
-title: "Apache Flink Code Style and Quality Guide — Pre
"Code Style - Component Guide" page into Chinese
klion26 commented on pull request #247:
URL: https://github.com/apache/flink-web/pull/247#issuecomment-621676247
@chaojianok thanks for your contribution. could you please get rid of the
`git merge` commit in the history. you can use `
klion26 commented on pull request #247:
URL: https://github.com/apache/flink-web/pull/247#issuecomment-621676247
@chaojianok thanks for your contribution. could you please get rid of the
`git merge` commit in the history. you can use `git rebase` or the other git
command to achieve it.
XBaith commented on a change in pull request #245:
URL: https://github.com/apache/flink-web/pull/245#discussion_r417749335
##
File path: contributing/code-style-and-quality-preamble.zh.md
##
@@ -1,25 +1,25 @@
---
-title: "Apache Flink Code Style and Quality Guide — Pre
klion26 commented on pull request #245:
URL: https://github.com/apache/flink-web/pull/245#issuecomment-621605899
Seems the original author's account has been deleted. maybe someone else can
take over this?
This is an automat
klion26 commented on a change in pull request #245:
URL: https://github.com/apache/flink-web/pull/245#discussion_r417746431
##
File path: contributing/code-style-and-quality-preamble.zh.md
##
@@ -1,25 +1,25 @@
---
-title: "Apache Flink Code Style and Quality Guide — Pre
klion26 edited a comment on pull request #242:
URL: https://github.com/apache/flink-web/pull/242#issuecomment-620981849
@shining-huang thanks for your contribution. could you please resolve the
conflict by rebasing the newly master?
klion26 commented on pull request #242:
URL: https://github.com/apache/flink-web/pull/242#issuecomment-620981849
@shining-huang thanks for your contribution. could you please resolve the
conflic by rebasing the newly master?
ce it.
> >
> > 3. I also agree with Piotr that problems with parameters reassignment
> > appear nearly exclusively in a very long methods. If we break long
> > methods in a shorter ones than there is usually no problem with a
> > parameter reassignment.
> >
> > 4. I
ak long
> methods in a shorter ones than there is usually no problem with a
> parameter reassignment.
>
> 4. I would be ok with adding a point to our code style guidelines, but
> honestly I am a bit skeptical. In the end we are not writing a book on
> how to write a good software, bu
reassignment.
4. I would be ok with adding a point to our code style guidelines, but
honestly I am a bit skeptical. In the end we are not writing a book on
how to write a good software, but we rather list the most important
problems that we've seen so far in Flink code base and how to better
> Hi,
>
> Couple of arguments to counter the proposal of making the `final` keyword
> obligatory. Can we prepare a code style/IDE settings to add it
> automatically? If not, I would be strongly against it, since:
>
> - Intellij’s automatic refactor actions will not work properly.
&g
Hi,
Couple of arguments to counter the proposal of making the `final` keyword
obligatory. Can we prepare a code style/IDE settings to add it automatically?
If not, I would be strongly against it, since:
- Intellij’s automatic refactor actions will not work properly.
- I don’t think it’s a big
ld be always final
>
> As described above, there is no reason a parameter to be non-final. So
> different with field,
> a field can be final or non-final based on whether or not it is immutable.
> Thus with such a
> code style guide in our community, we can work towards a cod
As described above, there is no reason a parameter to be non-final. So
different with field,
a field can be final or non-final based on whether or not it is immutable.
Thus with such a
code style guide in our community, we can work towards a codebase every
parameter is
effectively final.
2
gt;>> it’s always there (in other words, we shouldn’t be modifying the
>>> parameters). Did I understand this correctly?
>>>
>>> Piotrek
>>>
>>>> On 1 Oct 2019, at 21:44, Zili Chen wrote:
>>>>
>>>> Hi devs,
>>>>
&g
s,
>>>
>>> Coming from this discussion[1] I'd like to propose that in Flink codebase
>>> we suggest a code style
>>> that parameters of method are always final. Almost everywhere parameters
>> of
>>> method are final
>>> already and
he
> parameters). Did I understand this correctly?
>
> Piotrek
>
> > On 1 Oct 2019, at 21:44, Zili Chen wrote:
> >
> > Hi devs,
> >
> > Coming from this discussion[1] I'd like to propose that in Flink codebase
> > we suggest a code style
> >
at 21:44, Zili Chen wrote:
>
> Hi devs,
>
> Coming from this discussion[1] I'd like to propose that in Flink codebase
> we suggest a code style
> that parameters of method are always final. Almost everywhere parameters of
> method are final
> already and if we ha
Hi devs,
Coming from this discussion[1] I'd like to propose that in Flink codebase
we suggest a code style
that parameters of method are always final. Almost everywhere parameters of
method are final
already and if we have such consensus we can prevent redundant final
modifier in m
ore comments don't hesitate to add them here, if everyone
agrees I will open a PR in the next few days to add this to the code-style
guide!
Cheers,
Gyula
On Wed, Aug 28, 2019 at 1:37 PM Piotr Nowojski wrote:
> > For Piotr's comment 4. I. I agree with Klou that this sounds rather like
y be solved by introducing a transfer object.
>
> Cheers,
> Till
>
> On Tue, Aug 27, 2019 at 1:46 PM Timo Walther wrote:
>
>> Hi all,
>>
>> great to put this code style discussion on the mailing list because I
>> also have found this style inconsistent
ke a
problem of the builder's usage than a builder problem. I think such a
scenario can easily be solved by introducing a transfer object.
Cheers,
Till
On Tue, Aug 27, 2019 at 1:46 PM Timo Walther wrote:
> Hi all,
>
> great to put this code style discussion on the mailing list bec
Hi all,
great to put this code style discussion on the mailing list because I
also have found this style inconsistent in the past.
Regarding Gyula's suggestions:
1. a static method `builder()` I think IDEs are also hightlight methods
with this name
2. I would vote for a more declar
t; > > a) private constructor
> > > b) public constructor
> > >
> > > 5. setXXX methods of the main class
> > > a) setXXX methods are not allowed
> > > b) setXXX methods are allowed.
> > >
> > > I prefer both option a). Because I think one of the reason
cause I think one of the reason to have the
> > builder is that we don't want the constructor public.
> > A public constructor makes it hard to maintain and evolve compatibly when
> > adding new parameters, FlinkKafkaProducer is a good example.
> > For set methods, I think
eagerly (through the builder) and `setXXX` methods on the main class
> is duplicate with the methods on the builder. We should avoid that.
>
>
> Regards,
> Jark
>
>
> On Mon, 26 Aug 2019 at 20:18, Gyula Fóra wrote:
>
>> Hi All!
>>
>> I would like
ost cases, we want users to set the fields
eagerly (through the builder) and `setXXX` methods on the main class
is duplicate with the methods on the builder. We should avoid that.
Regards,
Jark
On Mon, 26 Aug 2019 at 20:18, Gyula Fóra wrote:
> Hi All!
>
> I would like to start a co
dize it
very strictly. I might be wrong though. Really looking forward to the
outcome of this discussion.
Best,
Dawid
On 26/08/2019 14:18, Gyula Fóra wrote:
> Hi All!
>
> I would like to start a code-style related discussion regarding how we
> implement the builder pattern in the Flink
Hi All!
I would like to start a code-style related discussion regarding how we
implement the builder pattern in the Flink project.
It would be the best to have a common approach, there are some aspects of
the pattern that come to my mind please feel free to add anything I missed:
1. Creating
ation, put into automation, we can
> activate it and/or reconsider.
> Nonetheless, I do not see any problem if we agree on this atm and make it
> part of our code style recommendations.
>
> Regarding putting the right parenthesis on the new line.
> At the moment we do not use this appro
of our code style recommendations.
Regarding putting the right parenthesis on the new line.
At the moment we do not use this approach in our code base. My personal
feeling is that it is not so often used in Java.
Anyways I think, this goes more into direction of the second follow-up to
discuss this
>> > > > > Hi Everybody,
>> > > > >
>> > > > > Thanks for your feedback guys and sorry for not getting back to
>> the
>> > > > > discussion for some time.
>> > > > >
>> > > > > @S
erned about putting the right parenthesis and/or
> throw
> > > > > clause on the next line
> > > > > because in general we do not it and there are a lot of variations
> of
> > > how
> > > > > and what to put to the next line so it needs
if you believe that it simplifies the code, example is in
> > [1]
> > >- Do not use Optional for class fields
> > >
> > > If there are no more comments/concerns/objections I will open a PR to
> > > reflect this in the code style guide.
exceptions and usually avoid them.
> > > > Although I am not a big fan of many function arguments either but
> this
> > > > seems to be a bigger problem in the code base.
> > > > I would be ok to not enforce anything for exceptions atm.
> > > >
> &g
t;method if you believe that it simplifies the code, example is in
> [1]
> >- Do not use Optional for class fields
> >
> > If there are no more comments/concerns/objections I will open a PR to
> > reflect this in the code style guide.
> >
>
in [1]
- Do not use Optional for class fields
If there are no more comments/concerns/objections I will open a PR to
reflect this in the code style guide.
Bets,
Andrey
[1]
https://github.com/apache/flink/blob/master/flink-formats/flink-avro/src/main/java/org/apache/flink/formats/avro
FYI the PR: https://github.com/apache/flink-web/pull/249
A review from the discussion participants would be appreciated.
On Tue, Aug 20, 2019 at 5:29 PM Andrey Zagrebin
wrote:
> I created an umbrella issue for the code style guide effort and a subtask
> for this discussion:
&
Andrey Zagrebin created FLINK-13812:
---
Summary: Code style for the usage of Java Optional
Key: FLINK-13812
URL: https://issues.apache.org/jira/browse/FLINK-13812
Project: Flink
Issue Type
the code style guide.
Bets,
Andrey
[1]
https://github.com/apache/flink/blob/master/flink-formats/flink-avro/src/main/java/org/apache/flink/formats/avro/typeutils/AvroFactory.java#L95
On Tue, Aug 20, 2019 at 10:35 AM Yu Li wrote:
> Thanks for the summarize Andrey!
>
> I'd also lik
a big fan of many function arguments either but this
> > > seems to be a bigger problem in the code base.
> > > I would be ok to not enforce anything for exceptions atm.
> > >
> > > @Chesnay Schepler
> > > Thanks for mentioning automatic checks.
> > &
I created an umbrella issue for the code style guide effort and a subtask
for this discussion:
https://issues.apache.org/jira/browse/FLINK-13804
I will also submit a PR to flink-web based on the conclusion.
On Mon, Aug 19, 2019 at 6:15 PM Stephan Ewen wrote:
> @Andrey Will you open a PR to
Andrey Zagrebin created FLINK-13802:
---
Summary: Flink code style guide
Key: FLINK-13802
URL: https://issues.apache.org/jira/browse/FLINK-13802
Project: Flink
Issue Type: Task
> I would be ok to not enforce anything for exceptions atm.
> >
> > @Chesnay Schepler
> > Thanks for mentioning automatic checks.
> > Indeed, pointing out this kind of style issues during PR reviews is very
> > tedious
> > and cannot really force it without automa
>>>>> when it is short lived. While it is easy to claim this is
> "premature
> > >>>>> optimization", as engineers it is our responsibility to know the
> > limits
> > >>>> and
> > >>>>> capabilities of the syste
em we work with and to choose carefully the
> >> point
> >>>>> where it should be stressed.
> >>>>>
> >>>>> And there's another JB blog about code smell on Null [4], which I'd
> >> also
> >>>>> suggest to read(smile).
> >>>>>
> >>
apache/flink/blob/master/flink-formats/flink-avro/src/main/java/org/apache/flink/formats/avro/typeutils/AvroFactory.java#L95
>>>>> [2] https://blog.jetbrains.com/idea/2016/07/java-8-top-tips/
>>>>> [3]
>> https://blog.joda.org/2015/08/java-se-8-optional-pragmatic-approach.h
nd cannot really force it without automated tools.
> I would still consider the outcome of this discussion as a soft
> recommendation atm (which we also have for some other things in the code
> style draft).
> We need more investigation about how to enforce things. I am not so
> know
@Andrey Will you open a PR to add this to the code style?
On Mon, Aug 19, 2019 at 11:51 AM Andrey Zagrebin
wrote:
> Hi All,
>
> It looks like this proposal has an approval and we can conclude this
> discussion.
> Additionally, I agree with Piotr we should really force
gt; > >>>>>
> > >>>>>
> > >>>>> On Fri, Aug 2, 2019 at 5:00 PM Zili Chen
> > wrote:
> > >>>>>
> > >>>>>> Hi Jark,
> > >>>>>>
> > >>>>>> Follow you
Yu
> >>>
> >>>
> >>> On Fri, 2 Aug 2019 at 14:54, JingsongLee >> .invalid>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>> First, Optional is just a wrapper, just like boxed value. So as long
> as
> >>>> it's
> >>
ion on the
> > collection size.
> >
> > Thank you~
> >
> > Xintong Song
> >
> >
> >
> > On Thu, Aug 1, 2019 at 2:32 PM Andrey Zagrebin
> wrote:
> >
> >> Hi all,
> >>
> >> As you probably already noticed, Stephan
tools.
I would still consider the outcome of this discussion as a soft
recommendation atm (which we also have for some other things in the code
style draft).
We need more investigation about how to enforce things. I am not so
knowledgable about code style/IDE checks.
>From the first glance I also
Jark Wu created FLINK-13684:
---
Summary: Translate "Code Style - Formatting Guide" page into
Chinese
Key: FLINK-13684
URL: https://issues.apache.org/jira/browse/FLINK-13684
Project: Flink
Jark Wu created FLINK-13683:
---
Summary: Translate "Code Style - Component Guide" page into Chinese
Key: FLINK-13683
URL: https://issues.apache.org/jira/browse/FLINK-13683
Project: Flink
Jark Wu created FLINK-13682:
---
Summary: Translate "Code Style - Scala Guide" page into Chinese
Key: FLINK-13682
URL: https://issues.apache.org/jira/browse/FLINK-13682
Project: Flink
Issue
Jark Wu created FLINK-13681:
---
Summary: Translate "Code Style - Java Guide" page into Chinese
Key: FLINK-13681
URL: https://issues.apache.org/jira/browse/FLINK-13681
Project: Flink
Issue
Jark Wu created FLINK-13680:
---
Summary: Translate "Code Style - Common Rules" page into Chinese
Key: FLINK-13680
URL: https://issues.apache.org/jira/browse/FLINK-13680
Project: Flink
Jark Wu created FLINK-13679:
---
Summary: Translate "Code Style - Pull Requests & Changes" page
into Chinese
Key: FLINK-13679
URL: https://issues.apache.org/jira/browse/FLINK-13679
Jark Wu created FLINK-13678:
---
Summary: Translate "Code Style - Preamble" page into Chinese
Key: FLINK-13678
URL: https://issues.apache.org/jira/browse/FLINK-13678
Project: Flink
Issue
Hi all,
I've now merged the guide to the Flink website:
https://flink.apache.org/contributing/code-style-and-quality-preamble.html
I'm looking forward to more pull requests enhancing the guide.
On Tue, Jul 23, 2019 at 7:22 PM Hugo Louro wrote:
> Sounds good @stephan! Thanks.
&g
as long as
>>>> it's
>>>> not a field level operation, I think it is OK to performance.
>>>> I think guava optional has a good summary to the uses. [1]
>>>>> As a method return type, as an alternative to returning null to
>> indicate
>>>> that
ype, as an alternative to returning null to
> indicate
> >> that no value was available
> >>> To distinguish between "unknown" (for example, not present in a map)
> >> and "known to have no value"
> >>> To wrap nullable references for storage
gt;> To wrap nullable references for storage in a collection that does not
>> support
>> The latter two points seem reasonable, but they have few scenes.
>>
>> [1]
>> https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Optional.java
>>
>> Best,
>> Jingsong Lee
>>
>>
>> --
> > *int arg1,*
> > *int arg2,*
> > *...
> > *) throws E1, E2, E3 {*
> > *...
> > *}*
> >
> > or
> >
> > *public **void func(*
> > *int arg1,*
> > *int arg2,*
> > *...
> > *) throws
> > *E1,
> > *E
t; Best,
> Jingsong Lee
>
>
> --
> From:Timo Walther
> Send Time:2019年8月2日(星期五) 14:12
> To:dev
> Subject:Re: [DISCUSS][CODE STYLE] Usage of Java Optional
>
> Hi everyone,
>
> I would vote for using O
tps://github.com/google/guava/blob/master/guava/src/com/google/common/base/Optional.java
Best,
Jingsong Lee
--
From:Timo Walther
Send Time:2019年8月2日(星期五) 14:12
To:dev
Subject:Re: [DISCUSS][CODE STYLE] Usage of Java Optional
Hi
PM, Andrey Zagrebin
wrote:
Hi all,
This is the next follow up discussion about suggestions for the
recent
thread about code style guide in Flink [1].
In general, one could argue that any variable, which is nullable,
can
be
replaced by wrapping it with Optional to explicitly show that it
can
b
uo wrote:
> > >
> > > > Agree that using Optional will improve code robustness. However we’re
> > > > hesitating to use Optional in data intensive operations.
> > > >
> > > > For example, SingleInputGate is already creating Optional for every
use Optional in data intensive operations.
> > > >
> > > > For example, SingleInputGate is already creating Optional for every
> > > > BufferOrEvent in getNextBufferOrEvent(). How much performance gain
> > would
> > > we
> > > > g
gt; > > BufferOrEvent in getNextBufferOrEvent(). How much performance gain
> would
> > we
> > > get if it’s replaced by null check?
> > >
> > > Regards,
> > > Qi
> > >
> > > > On Aug 1, 2019, at 11:00 PM, Andrey Zagrebin
> &
ck?
> >
> > Regards,
> > Qi
> >
> > > On Aug 1, 2019, at 11:00 PM, Andrey Zagrebin
> > wrote:
> > >
> > > Hi all,
> > >
> > > This is the next follow up discussion about suggestions for the recent
> > > thread about co
; > On Aug 1, 2019, at 11:00 PM, Andrey Zagrebin
> wrote:
> >
> > Hi all,
> >
> > This is the next follow up discussion about suggestions for the recent
> > thread about code style guide in Flink [1].
> >
> > In general, one could argue that any variable,
t arg1,*
> *int arg2,*
> *...
> *) throws
> *E1,
> *E2,
> *E3 {*
> *...
> *}*
>
> Regards,
> Xiaogang
>
> Andrey Zagrebin 于2019年8月1日周四 下午11:19写道：
>
> > Hi all,
> >
> > This is one more small suggestion for the recent thread a
Just so everyone remembers:
Any suggested code-style should be
a) configurable in the IDE (otherwise we'll never be able to auto-format)
b) be verifiable via checkstyle (otherwise we'll end up manually
checking for code-style again)
On 02/08/2019 03:20, SHI Xiaogang wrote:
Hi Andre
null check?
Regards,
Qi
> On Aug 1, 2019, at 11:00 PM, Andrey Zagrebin wrote:
>
> Hi all,
>
> This is the next follow up discussion about suggestions for the recent
> thread about code style guide in Flink [1].
>
> In general, one could argue that any variable, w
：
> Hi all,
>
> This is one more small suggestion for the recent thread about code style
> guide in Flink [1].
>
> We already have a note about using a new line for each chained call in
> Scala, e.g. either:
>
> *values**.stream()**.map(...)**,collect(...);*
>
&g
stions for the recent
> thread about code style guide in Flink [1].
>
> In general, one could argue that any variable, which is nullable, can be
> replaced by wrapping it with Optional to explicitly show that it can be
> null. Examples are:
>
> - returned values to force user
EDIT: for Optional in public API vs performance concerns
Hi all,
This is the next follow up discussion about suggestions for the recent
thread about code style guide in Flink [1].
In general, one could argue that any variable, which is nullable, can be
replaced by wrapping it with Optional to
Hi all,
This is one more small suggestion for the recent thread about code style
guide in Flink [1].
We already have a note about using a new line for each chained call in
Scala, e.g. either:
*values**.stream()**.map(...)**,collect(...);*
or
*values*
*.stream()*
*.map
PM Andrey Zagrebin wrote:
>
>> Hi all,
>>
>> As you probably already noticed, Stephan has triggered a discussion thread
>> about code style guide for Flink [1]. Recently we were discussing
>> internally some smaller concerns and I would like start separate threads
&g
Hi all,
This is the next follow up discussion about suggestions for the recent
thread about code style guide in Flink [1].
In general, one could argue that any variable, which is nullable, can be
replaced by wrapping it with Optional to explicitly show that it can be
null. Examples are
+1 on setting initial capacity only when have good expectation on the
collection size.
Thank you~
Xintong Song
On Thu, Aug 1, 2019 at 2:32 PM Andrey Zagrebin wrote:
> Hi all,
>
> As you probably already noticed, Stephan has triggered a discussion thread
> about code style guide
Hi all,
As you probably already noticed, Stephan has triggered a discussion thread
about code style guide for Flink [1]. Recently we were discussing
internally some smaller concerns and I would like start separate threads
for them.
This thread is about creating collections always with initial
le in mind and they can only focus on
> > functionality
> > > >> they want to fix, and it's also great for reviewers, because they
> only
> > > see
> > > >> the important changes. This also eliminates need for any special
> > editor
> > > /
1 - 100 of 245 matches
Mail list logo
