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 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 method
declaratio
12 matches
Mail list logo
