Just to *wrap up* this thread: *I'm with-drawing my proposal.*
We do not have any sort of consensus (rough or otherwise) regarding the use
of final on local variables.
Thanks to everyone who participated!
On Thu, Jun 13, 2019 at 1:31 PM Kirk Lund wrote:
> According to Effective Java 3rd
Thanks for the very thoughtful and well-worded reply, Bill. I would
certainly welcome further discussion on how and where to consistently use
the final keyword (if that's desirable), especially within the context of
reviewing pull requests.
On Wed, Jun 19, 2019 at 11:23 AM Bill Burcham wrote:
>
-1 to the proposal as I understand it:
Premise:
a. Because the "final" modifier on local variables serves no function other
than to inform compiler optimization and…
b. because the compiler can tell if a variable is "effectively final"
without an explicit "final" modifier in the source code
I agree with Darrel, Bill has made some very compelling arguments.
I also add my vote of -1 to remove "noisy" final keywords from local
variables.
I am VERY interested in understanding how the JVM would handle this, as
final is a keyword that stops the reassignment of the variable with
I find Bill's argument of using final by default on everything convincing
and removing it when you have something that needs to be changed.
It is not in keeping with my current practice but I'm willing to change.
So I vote -1 to not using "final" on local variables.
On Wed, Jun 19, 2019 at 7:29
Just to confirm, the primary place where we make project decisions is on the
dev@geode list. Thanks!
Anthony
> On Jun 19, 2019, at 7:19 AM, Bill Burcham wrote:
>
> I feel that a lot more
> conversation is needed, outside email. On the other hand, this mailing list
> is a fine place to
Shorter methods are better! Code is indeed better when it's understandable
in smaller chunks.
The reason shorter methods are better is because there is less you have to
hold in your mind when evaluating them. That's why I make fields, method
parameters, and local variables final by default—when
I recommend:
* Use final if you want to
* Don’t -1 someone’s PR because they did or didn’t use final.
Personally, there is one case where I like to use final on a local variable:
forcing the compiler to tell me if I’ve covered all code paths. Here’s a very
simple example:
final int x;
if
+1 to everything Bill said
+1 to what Anthony recommended
I think that we in many cases we should not confuse scope with variable
reassignment.
And we should not confuse variable reassignment with methods that affect
change of a local object. Stateful objects don't have to be immutable
and
What does "rough consensus"[1] look like on this thread? How do we make a
decision and close it out?
Kirk suggested an idea, there’s been a couple days of feedback, so we can:
1) reject the proposal and commit to using final ‘everywhere'
2) accept the proposal and use final very sparingly
3)
I agree with Murtuza, most finals on local variables and method parameters
are just noise to me. I only use "final" on these two situations:
1. to declare public static constants of immutable types (e.g. String,
Integer)
2. to prevent children from overriding a method.
But thought I can't offer
I’ll offer this alternative: perhaps shorter method bodies obviate the need
for explicit final vars.
Anthony
> On Jun 18, 2019, at 10:30 AM, Ernest Burghardt wrote:
>
> +1 to auto-enforcement (if possible) post-consensus
>
> On Tue, Jun 18, 2019 at 8:33 AM Murtuza Boxwala wrote:
>
>>
+1 to auto-enforcement (if possible) post-consensus
On Tue, Jun 18, 2019 at 8:33 AM Murtuza Boxwala wrote:
> final in Java does not guarantee immutability. It would be AWESOME if it
> did but all it guarantees is that the variable cannot be reassigned. In
> most cases the variable points to an
final in Java does not guarantee immutability. It would be AWESOME if it did
but all it guarantees is that the variable cannot be reassigned. In most cases
the variable points to an object’s location (memory address), so you can still
call methods on it, e.g.
final var = new Foo();
I too am in camp final too. You could say `final boolean useFinal = true`. For
all the same reasons Bill stated below.
> On Jun 17, 2019, at 5:33 PM, Bill Burcham wrote:
>
> The final keyword is not redundant—quite the opposite—it's extremely valuable.
>
> Local variables are not, in general,
The final keyword is not redundant—quite the opposite—it's extremely
valuable.
Local variables are not, in general, final, unless you declare them as
such. That being the case, it is not redundant to declare local variables
"final".
What the compiler will do for you, is _if_ it can ensure that a
> On Jun 13, 2019, at 1:31 PM, Kirk Lund wrote:
>
> According to Effective Java 3rd Edition, all local variables are implicitly
> made final by the JVM…
Can you please provide a link or at least the chapter and item number that this
statement is made in. I have scanned through the book and
> On Jun 13, 2019, at 4:15 PM, Ryan McMahon wrote:
>
> I agree with this sentiment, and have generally only been using final on
> class fields and method parameters where I want to guarantee immutability
> as of late. However, I was at one time adding final to local variables,
> and I know
> On Jun 13, 2019, at 4:29 PM, Juan José Ramos wrote:
>
> +1 to removing *final* on local variables.
> However, regarding Ryan's example, and even if it adds some "noise" to the
> source code, I'm in favour of keeping the *final* keyword on local
> variables whenever the developer wants to
+1 to removing *final* on local variables.
However, regarding Ryan's example, and even if it adds some "noise" to the
source code, I'm in favour of keeping the *final* keyword on local
variables whenever the developer wants to explicitly show the intent of
making that the variable effectively
I agree with this sentiment, and have generally only been using final on
class fields and method parameters where I want to guarantee immutability
as of late. However, I was at one time adding final to local variables,
and I know that I have checked in code with final locals. Should we
actively
21 matches
Mail list logo
