Re: Unnecessary uses of final on local variables

[Dale Emery]

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

My preference (fairly strong) is not to mark locals and parameters as final, 
but I won’t go so far as to say it’s invalid to do so.

I would like to know more about the intent, so …

If such a local variable were not marked final, what bad thing do you think 
might happen?

A more positive version of the same question: If you’re able to show that the 
variable is effectively constant, what good things does that do for you?

—
Dale Emery
dem...@pivotal.io

Re: Unnecessary uses of final on local variables

[Dale Emery]

> 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 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  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  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  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]  [image: twitter]
>  [image: linkedin]
>  [image: facebook]
>  [image: google plus]
>  [image: youtube]
> 

Re: Unnecessary uses of final on local variables

[Juan José Ramos]

+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  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  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]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

[DISCUSS] RFC 0: Lightweight RFC Process

[Alexander Murmann]

Hi everyone,

I am proposing a new process that is aimed to address some of the issues
we've recently encountered in making collective decisions. The process I am
proposing would use pull request to discuss proposals.

To demonstrate the process, I submitted my proposal as a pull request
. While this email has the
[DISCUSS] label, I ask to *please keep all discussions on the PR
* to test drive the proposed
process. There already is a healthy discussion on the PR, including if the
process in general should take place via a PR.

Thanks!

Re: Unnecessary uses of final on local variables

[Ryan McMahon]

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

Unnecessary uses of final on local variables

[Kirk Lund]

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.