"+1" to ENCOURAGING developers to make "final" a requirement for method
arguments.
"-1" to making it a hard rule.
If we want to enforce this rule on the basis of readability or performance, I
fear that we might be beating the wrong horse here for the wrong reasons!!
Short reasoning:
If we really want to effect real lasting change, is to adopt principles that
Rust (object owners) and Kotlin (immutable collections) make core to the
language. Immutable POJOs and possibly an extension for collections to make
intent of immutability clear would be far more effective. As code reviewers
would be able to look at a method definition and instantly know what arguments
are mutable.
Adding "final" on fields, methods and classes has a far greater effect than
that of method arguments. If we intent to enforce it based on readability, then
we should really consider applying different approaches (as stated in the
paragraph above) that can be used with far greater effectiveness.
Longer reasoning:
I think all arguments relating to "indicating authors intent" or "variable
does not change" are great, but in reality we as developers should always
assume that this was the intent. I think if we really want to improve our code
base, let's opt for IMMUTABLE data objects. The "final" keyword has no benefit
if you pass around POJOs (including Collections). As long as you don't change
the instance reference, the "final" keyword has absolutely no effect. It does
not mean that you cannot change every field internal of the POJO. The "final"
keyword is only effective against the re-assignment of that variable/argument
within a method. But a better practice is to avoid the re-assignment of any
variable/argument in the first place.
Kotlin has a great language (one of many) that method/function arguments are
naturally final and this behavior cannot be changed. In addition there is a the
feature that the collections are immutable and as a developer you have to be
explicit if you want a collection to be mutable, by defining the collection as
a "Mutable*" i.e MutableMap, MutableSet, MutableList
@Jake the idea of smaller methods is great and we should ALWAYS strive for
that. But that argument is completely irrelevant in this discussion. As making
method arguments final does not naturally guide a developer to creating smaller
methods. Nor does a smaller method mean it can/will be jitted. Too many factors
(to discuss here) are part of that decision, also it is not relevant in this
discussion. But more on that topic read THIS.
--Udo
On 4/15/21, 9:29 AM, "Jacob Barrett" <jabarr...@vmware.com> wrote:
If a method is longer than a handful of lines and I go in to refactor it I
am going to start by making every variable I find final. Then I am going to
figure out how to keep them final. By doing so you naturally produce smaller
functional methods that are usually independently unit testable. Smaller
methods can get jitted. Smaller methods can take less time to reach a safe
point (see time to safe point issues in Java).
For this reason I strongly prefer on final everywhere and if you think you
need a variable to not be final you should use that as an indicator to
refractor your code.
So, +1 for me for final everywhere.
Also, please stop declaring variables miles away from their use.
> On Apr 14, 2021, at 12:55 PM, Kirk Lund <kl...@apache.org> wrote:
>
> Our coding standard and our Design Decisions does NOT require using final
> on parameters and local variables.
>
> Please do NOT request that I add or keep final on parameters or local
> variables unless the community votes and decides that every parameter and
> local variable should require the final keyword. I coded this way in the
> past and I found that it resulted in noisy code with no benefit. We can
> argue about using this keyword all you want but the fact is I'm against
it,
> and I will not embrace it unless this community decides that we need to
use
> it.
>
> Using final on instance or class fields does have a concurrency benefit
and
> I support that only.
>
> If you want to add final to every single parameter and local var in the
> Geode codebase, then now is your chance to vote on it. Please vote.
>
> Thanks,
> Kirk
