I don't think we need final or any local variables unless the language
mandates it. I think it just adds noise.
Paul
On Thu, Jan 10, 2013 at 5:53 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 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 <garydgreg...@gmail.com> wrote:
>>> Hi,
>>> On Thu, Jan 10, 2013 at 4:39 PM, Ralph Goers
>>> <ralph.go...@dslextreme.com>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 <garydgreg...@gmail.com>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: garydgreg...@gmail.com | ggreg...@apache.org
>>>>> 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: garydgreg...@gmail.com | ggreg...@apache.org
>>>> 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: garydgreg...@gmail.com | ggreg...@apache.org
>>> 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: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
