Yeah, understood just an opinion about noise __ The clarity and precision part
I'm debating a bit but I also don't do code review or work in the actual code
base as much as before so I'll go with a -0 vote for me and let everyone else
that does see the code more often decide __
On 4/14/21, 4:28 PM, "Robert Houghton" <rhough...@vmware.com> wrote:
Does this really "add noise" instead of "add clarity and precision" ?
-Robert
On 4/14/21, 4:25 PM, "Jason Huynh" <jhu...@vmware.com> wrote:
Just to confirm for myself... final doesn't necessarily make object
immutable.. the reference is immutable but if it refers to say a list, the list
is still mutable.
So if I see a final keyword, I should only expect the reference not to
change, but it won't guarantee that the object isn't changing.
I'm a -1 on forcing the issue because I believe we currently have too
many "edge cases" where we can't stick a final on. So we end up adding
complexity in reading without the benefit guaranteeing anything... I'd dislike
seeing something like this make it partway and then get abandoned...
Also are we only discussing local variables, class variables and method
parameters? Ignoring final on methods and classes?
On 4/14/21, 2:18 PM, "Mark Hanson" <hans...@vmware.com> wrote:
+1 To Kirk’s approach.
-1 To final everywhere.
I support Kirk’s approach of adding final where there is benefit.
If we want to go further, we can have intellij find all of them and change them
if we want. Final is not always a developer’s explicit statement. Sometimes
something becomes final after the fact.
If we manually touch any code, I would much rather we deal with the
use of raw types than have final everywhere. This strikes me as a minor issue
compared to the rampant use of raw types.
E.g.
RegionFactory regionFactory =
getCache().createRegionFactory(RegionShortcut.PARTITION_REDUNDANT);
Region region = regionFactory.create (“testRegion”);
Region.put(int, String);`
Thanks,
Mark
From: Bill Burcham <bill.burc...@gmail.com>
Date: Wednesday, April 14, 2021 at 1:53 PM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: [VOTE] Requiring final keyword on every parameter and
local variable
+1
I am 100% for putting final everywhere it is possible to put it.
Call this
the "hard final" position.
What I've been advocating for, intermittently, in PRs (for example,
in PR
#6310
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6310%23discussion_r612710322&data=04%7C01%7Cjhuynh%40vmware.com%7Cfd64a4ac6e3b450cd1a508d8ff9d0a44%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637540397240628225%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CpfN5mam1U5TNNWIPX8%2BLx8ZHp80u78nKogPDp9Q%2BQU%3D&reserved=0>)
is
more of a "soft final" position which I can formulate as:
The final keyword is valuable everywhere. When we encounter it in
code, we
assume that the author put it there intentionally to communicate
that the
variable will not change. Since the code compiled before our
change, we
know that the variable does not change (the compiler has proven
it!) When
modifying code, we do not remove the final keyword unless we have
to (to
get the code to compile).
So that's the "soft final" position. But I'm all for Kirk's "hard
final" if
others agree. I just don't see any downside—only upside on this one.
The final keyword is a vehicle, like types, for programmers to
communicate
their intentions. In both cases, the compiler can provide valuable
validation. There is, unfortunately, some visual noise entailed
(lots of
occurrences of "final" in the code). But this makes non-final
(mutable)
variables much more apparent. Since they are (or should be) in the
minority, this is an aid to maintainers. This becomes apparent in
longer,
more complex methods.
On Wed, Apr 14, 2021 at 12:56 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
>
