I agree, with the exception of local variables. If you look at the last
commits he made they were primarily to mark variables defined within a method
as final. From a compiler/performance point of view these don't provide any
real value. For example, one of the changes Gary made was similar to
from
Iterator<Provider> providers = ProviderUtil.getProviders();
while (providers.hasNext()) {
Provider provider = provider.next();
....
}
to
final Iterator<Provider> providers = ProviderUtil.getProviders();
while (providers.hasNext()) {
final Provider provider = provider.next();
...
}
While I have no great objection to this I find it to be of minimal value. In
general, methods and blocks should be fairly short so the "clarity" declaring
these variable final provides isn't of much value to me.
Ralph
On Jan 10, 2013, at 3:12 PM, Jacob Kjome wrote:
>
> +1
>
> I couldn't agree with Gary more. The "final" keyword is an essential element
> to bug free programs for all the reasons he provides.
>
> Jake
>
> On Thu, 10 Jan 2013 16:59:08 -0500
> Gary Gregory <[email protected]> wrote:
>> Hi,
>> On Thu, Jan 10, 2013 at 4:39 PM, Ralph Goers
>> <[email protected]>wrote:
>>> I guess I should have replied.
>>>
>>> My attitude is "I don't care but don't expect me to always do it".
>>>
>> Sure, to each his own :)
>>> Mainly, this is because I have no idea what, if any, benefit there is to
>>> declaring a variable that is local to a method as final. They don't affect
>>> thread safety and, as far as I am aware, don't improve the performance of
>>> the code. If you can find something that shows significant benefit then
>>> maybe I'll get in the habit of doing it too.
>>>
>> What I like about final on locals is that it lets me define and guard
>> "local constants" that I cannot modify because the compiler will complain.
>> This lets me put in code my intention that a local var should not be
>> modified.
>> It helps avoid coding mistakes.
>> Putting final on params formalizes the convention that parms should not be
>> overwritten, if you like that convention that is. IMO, it makes debugging
>> easier and coding easier, you know that when you access a final param
>> value, it has not been changed.
>>> As far as class variables, those I have a much stronger opinion about.
>>> They should be declared final whenever possible.
>>>
>> Same for instance variable when possible if immutable objects are desired
>> for thread-safety.
>> Cheers,
>> Gary
>>>
>>> Ralph
>>>
>>>
>>>
>>>
>>> On Jan 10, 2013, at 12:15 PM, Gary Gregory wrote:
>>>
>>> Since there is no negative feedback, I'll add final keywords.
>>>
>>> Gary
>>>
>>>
>>> On Tue, Oct 9, 2012 at 9:08 AM, Gary Gregory <[email protected]>wrote:
>>>
>>>> Hi All:
>>>>
>>>> The final keyword in trunk: sometimes it is used, sometimes not. I
>>>> propose we use it all over consistently.
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: [email protected] | [email protected]
>>>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
>>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: [email protected] | [email protected]
>>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>> --
>> E-Mail: [email protected] | [email protected]
>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
