Really? Final variables don't provide any compiler optimization in a loop?
Anyway, I'd have changed it to...
for (final Provider provider : ProviderUtil.getProviders()) {
//do some stuff...
}
Not all method blocks are only 3 lines long, and it's not always just one or
two people working on the code. Final variables provide intention. Some
local vars are meant to be overwritten. When they are not, they should be
explicitly declared as such, which makes it a compiler error when someone
accidentally tries to modify it. Whether or not you think this provides much
benefit, it does eliminate one class of potential bugs, which is a good thing.
Besides, they are essential if you want to reference a local variable in a
closure, or locally implemented callback method, though I suspect you'd have
no argument with that.
Jake
On Thu, 10 Jan 2013 17:55:31 -0600
Paul Benedict <pbened...@apache.org> wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
