For Piotr's comment. IntelliJ does support adding/removing final parameters
automatically.
You could even automatically add them on save with the Save Actions plugin
[1].
[1] https://plugins.jetbrains.com/plugin/7642-save-actions
On Mon, Oct 7, 2019 at 11:22 AM Piotr Nowojski wrote:
> After ch
After checking out the check style modules mentioned by Tison, I really do not
see a point of enforcing/adding `final`. With ParameterAssignment [1] it’s
redundant and will cause problems that I mentioned before.
Additionally enabling ParameterAssignment [1] would be probably much easier in
our
Hi all,
My quick take on it.
1. If I were to introduce any rule on that I agree with Aljoscha, we
should rather enforce the `final` keyword rather than the opposite.
2. I think it does not make sense to enforce rules on such an
unimportant (in my opinion) topic. Generally I agree with Piotr that
Thanks for your thoughts Arvid & Piotr,
I check out the effect of ParameterAssignment[1] and it does
prevent codes from modifying parameter which I argued above
the most value introduced by `final` modifier of parameter.
So firstly, I think it's good to enable ParameterAssignment in our
codebase.
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 d
Hi guys,
I'm a bit torn. In general, +1 for making parameters effectively final.
The question is how to enforce it. We can make it explicit (like Aljoscha
said). All IDEs will show immediately warnings/errors for violations. It
would allow to softly migrate code.
Another option is to use a check
Hi Aljoscha,
I totally agree with you on field topic. Of course it makes significant
difference whether
or not a field is final and IDE/compiler can help on checking.
Here are several thoughts about final modifier on parameters and why I
propose this one:
1. parameters should be always final
As
I actually think that doing this the other way round would be correct. Removing
final everywhere and relying on humans to assume that everything is final
doesn’t seem maintainable to me. The benefit of having final on
parameters/fields is that the compiler/IDE actually checks that you don’t
mod
+1 from my side.
> On 2 Oct 2019, at 13:07, Zili Chen wrote:
>
> Yes exactly.
>
>
> Piotr Nowojski 于2019年10月2日周三 下午7:03写道：
>
>> Hi Tison,
>>
>> To clarify your proposal. You are proposing to actually drop the
>> `final` keyword from the parameters and we should implicilty assume that
>
Yes exactly.
Piotr Nowojski 于2019年10月2日周三 下午7:03写道：
> Hi Tison,
>
> To clarify your proposal. You are proposing to actually drop the
> `final` keyword from the parameters and we should implicilty assume that
> it’s always there (in other words, we shouldn’t be modifying the
> parameters).
Hi Tison,
To clarify your proposal. You are proposing to actually drop the `final`
keyword from the parameters and we should implicilty assume that 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
Hi all,
Thank you all for the valuable feedback, let me try to summarize the rough
agreement:
If there is a builder for class A, then A should:
- Have only private ctor -> force usage of the builder
- Be immutable (no setters)
- Have a public static .builder(required params if not too many) m
> For Piotr's comment 4. I. I agree with Klou that this sounds rather like 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.
It could be solved, but that would mean we have some kind of
builder/factory/descr
Hi all,
I would be in favour of the following convention
1. a) static method for builder creation
2. No strict rule because especially for boolean flags it might make sense
to have something like `enableX()` or `withY()` where one doesn't specify a
concrete value.
3. Mutable builders but if there
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 declarative `prop
Hi all,
I agree with Arvid, although for point 2 I would be less strict.
@Piotr, for the side note you mentioned, and from the description you
mention in the mail for example I,
it seems that the need to pass parameters in the build() is not an
inherent need of the build pattern but it
can be mit
Hi all,
I'd like to differentiate between API level builder usage and "internal"
builder usage (for example, test harness).
For API level builder, in general everything goes, as long as it aligns
with user expectations. API level usages are also much more discussed, such
that I'd expect them to b
Hi,
I agree with Dawid, modulo that I don’t have any preference about point 2 - I’m
ok even with not enforcing this.
One side note about point 4. There are use cases where passing obligatory
parameters in the build method itself might make sense:
I. - when those parameters can not be or can n
Hi Gyula,
Thanks for bringing this. I think it would be nice if we have a common
approach to create builder pattern.
Currently, we have a lot of builders but with different tastes.
> 1. Creating the builder objects:
I prefer option a) too. It would be easier for users to get the builder
instance
Hi Gyula,
A few comments from my side.
Ad. 1 Personally I also prefer a static method in the "built" class. Not
sure if I would be that strict about the "Builder" suffix, though. It is
usually quite easy to realize the method returns a builder rather than
the object itself. In my opinion the suff
Creating a JIRA issue [1] is done.
Regards,
Chiwan Park
[1] https://issues.apache.org/jira/browse/FLINK-2539
> On Aug 18, 2015, at 5:28 PM, Till Rohrmann wrote:
>
> Good initiative Chiwan. +1 for a more unified code style.
>
> On Tue, Aug 18, 2015 at 10:25 AM, Chiwan Park wrote:
>
>> Okay,
Good initiative Chiwan. +1 for a more unified code style.
On Tue, Aug 18, 2015 at 10:25 AM, Chiwan Park wrote:
> Okay, I’ll create a JIRA issue covered this topic.
>
> Regards,
> Chiwan Park
>
> > On Aug 17, 2015, at 1:17 AM, Stephan Ewen wrote:
> >
> > +1 for formatting templates for Eclipse a
Okay, I’ll create a JIRA issue covered this topic.
Regards,
Chiwan Park
> On Aug 17, 2015, at 1:17 AM, Stephan Ewen wrote:
>
> +1 for formatting templates for Eclipse and IntelliJ.
>
> On Sun, Aug 16, 2015 at 6:06 PM, Sachin Goel
> wrote:
>
>> We should also write up a matching configuration
+1 for formatting templates for Eclipse and IntelliJ.
On Sun, Aug 16, 2015 at 6:06 PM, Sachin Goel
wrote:
> We should also write up a matching configuration file to be used in the
> IDEs and provide it with the source. This might help in reducing any style
> mistakes due to a reformat, which is
We should also write up a matching configuration file to be used in the
IDEs and provide it with the source. This might help in reducing any style
mistakes due to a reformat, which is actually very helpful with spaces
around braces and operators. Especially with Scala, indentations and
continuation
Hi!
I very much support that. A bit stricter rules in the style checkers lead
to more uniform and better readable code. We can have stricter rules both
in Java and Scala.
Note that the hardest part of adding the style checks is actually adjusting
all the existing code that violates the style.
Th
Despite Flink's superb code quality :), only few code style rules exist. In
previous discussions we found that very strict code style rules do not
necessarily lead to better code readability and quality. The community
follows a pragmatic best-effort approach instead. Aljoscha already pointed
you to
These are the only format coding guidelines I'm aware of:
http://flink.apache.org/coding-guidelines.html
Some other stuff (such as space between 'if' and open parentheses) is
implicit. It seems to be common Java style and the code that we
already have follows it. I would say that the existing code
28 matches
Mail list logo
