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. >
