FYI PR: https://github.com/apache/flink-web/pull/254
On Thu, Aug 22, 2019 at 10:11 AM Andrey Zagrebin
wrote:
> Hi Tison,
>
> Regarding the automatic checks.
> Yes, I suggest we conclude the discussion without the automatic checks.
> As soon as we have more ideas/investigation, put into automatio
Hi Tison,
Regarding the automatic checks.
Yes, I suggest we conclude the discussion without the automatic checks.
As soon as we have more ideas/investigation, 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 o
One more question, what do you differ
*public **void func(*
*int arg1,*
*int arg2,*
*...)** throws E1, E2, E3 {*
*...*
*}*
and
*public **void func(*
*int arg1,*
*int arg2,*
*...
*)** throws E1, E2, E3 {*
*...*
*}*
I prefer the latter becau
Thanks Andrey for driving the discussion. Just for clarification,
what we conclude here are several guidelines without automatic
checker/tool guard them, right?
Best,
tison.
Andrey Zagrebin 于2019年8月21日周三 下午8:18写道：
> Hi All,
>
> I suggest we also conclude this discussion now.
>
> Breaking the l
Hi All,
I suggest we also conclude this discussion now.
Breaking the line of too long statements (line longness is yet to be fully
defined) to improve code readability in case of
- Long function argument lists (declaration or call): void func(type1
arg1, type2 arg2, ...)
- Long sequence
Implement question: how to apply the line length rules?
If we just turn on checkstyle rule "LineLength" then a huge
effort is required to break lines those break the rule. If
we use an auto-formatter here then it possibly break line
"just at the position" awfully.
Is it possible we require only t
I second Stephan's summarize, and to be more explicit, +1 on:
- Set a hard line length limit
- Allow arguments on the same line if below length limit
- With consistent argument breaking when that length is exceeded
- Developers can break before that if they feel it helps with readability
FWIW, hba
I personally prefer not to break lines with few parameters.
It just feels unnecessarily clumsy to parse the breaks if there are only
two or three arguments with short names.
So +1
- for a hard line length limit
- allowing arguments on the same line if below that limit
- with consistent argum
Hi Everybody,
Thanks for your feedback guys and sorry for not getting back to the
discussion for some time.
@SHI Xiaogang
About breaking lines for thrown exceptions:
Indeed that would prevent growing the throw clause indefinitely.
I am a bit concerned about putting the right parenthesis and/or th
Hi Chesnay,
Thanks a lot for your reminder.
For Intellij settings, the style i proposed can be configured as below
* Method declaration parameters: chop down if long
* align when multiple: YES
* new line after '(': YES
* place ')' on new line: YES
* Method call arguments: chop down if
Hi Andrey,
Thank you for bringing us this discussion.
I would like to make some details clear. Correct me if I am wrong.
The guide draft [1] says the line length is limited in 100 characters. From
my understanding, this discussion suggests if there is more than 100
characters in one line (both S
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 Andrey,
Thanks
Hi Andrey,
Thanks for bringing this. Personally, I prefer to the following style which
(1) puts the right parenthese in the next line
(2) a new line for each exception if exceptions can not be put in the same
line
That way, parentheses are aligned in a similar way to braces and exceptions
can be
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(*...*)*
*.col
14 matches
Mail list logo
