geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Emery <dem...@pivotal.io>
Subject Re: Unnecessary uses of final on local variables
Date Fri, 14 Jun 2019 00:28:32 GMT

> On Jun 13, 2019, at 4:29 PM, Juan José Ramos <jramos@pivotal.io> 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 explicitly show the intent of
> making that the variable effectively constant.

How will we know whether it’s an explicit intention, vs an old habit or something else?

—
Dale Emery
demery@pivotal.io



> On Jun 13, 2019, at 4:29 PM, Juan José Ramos <jramos@pivotal.io> 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 explicitly show the intent of
> making that the variable effectively constant.
> Cheers.
> 
> 
> On Fri, Jun 14, 2019 at 12:15 AM Ryan McMahon <rmcmahon@pivotal.io> 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 that I have checked in code with final locals.  Should we
>> actively be removing finals when we see it on locals?
>> 
>> One case where I still have been using final for locals is when the
>> variable is effectively constant and I want to show that intent.  For
>> instance:
>> final String resourceId =
>> "someStaticResourceIdThatReallyShouldntBeReassignedEver";
>> 
>> Is this a valid use case or should we view this as unnecessary verbosity as
>> well?
>> 
>> Thanks,
>> Ryan
>> 
>> 
>> 
>> On Thu, Jun 13, 2019 at 1:31 PM Kirk Lund <klund@apache.org> wrote:
>> 
>>> According to Effective Java 3rd Edition, all local variables are
>> implicitly
>>> made final by the JVM (and thus receiving the same JVM optimizations as a
>>> final variable) without requiring use of the keyword as long as you only
>>> set the value once. So this becomes an unnecessary use of the keyword
>>> final which
>>> really just adds noise to the code (one more word on many lines) much
>> like
>>> unnecessary uses of this. on references to class fields. The only context
>>> where it's still valuable to use final is on class fields and constants
>>> where it provides concurrency guarantees.
>>> 
>>> It may be useful to temporarily mark a local variable as final while
>>> performing a refactoring. See Martin Fowler's book for various
>> refactorings
>>> in which he does this.
>>> 
>>> There really is no value in retaining the keyword on a local variable any
>>> longer, so I think we should avoid using it in the same way we avoid
>>> unnecessary uses of this. on references to class fields. It's all just
>> more
>>> noise in the code.
>>> 
>> 
> 
> 
> -- 
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
> 
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message