-1 for requiring final for all method parameters. While I have nothing against using final here, I don’t think it’s worth mandating and would be better left up to the individual and the specific circumstance.
On Apr 14, 2021, at 4:33 PM, Jason Huynh <jhu...@vmware.com<mailto:jhu...@vmware.com>> wrote: 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<mailto: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<mailto: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<mailto: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<mailto:bill.burc...@gmail.com>> Date: Wednesday, April 14, 2021 at 1:53 PM To: dev@geode.apache.org<mailto:dev@geode.apache.org> <dev@geode.apache.org<mailto: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%7Cjpatrick%40vmware.com%7C5df09b1eacad48722f0708d8ff9db7d5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637540400159396125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Oz4syWeYiLGnZTPg7YFGgCvT7kqVu4J%2BTfgDvYN0Qa4%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<mailto: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
