> On Jun 13, 2019, at 4:29 PM, Juan José Ramos <jra...@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 dem...@pivotal.io > On Jun 13, 2019, at 4:29 PM, Juan José Ramos <jra...@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 <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>
