+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 <rmcma...@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 <kl...@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: jra...@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>
