On Thu, Jan 10, 2013 at 6: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();
> ...
> }
>
It all depends on what "..." contains doesn't it? If it's a simple
one-liner-single-method-call-with-no-args, the "final" may seem overkill,
but it is more complex it is not IMO. This is all about communicating
intent. I prefer to use final consistently than making a judgement call on
whether this or that declaration benefits. Either the value is constant or
it is not.
>
> 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.
>
Great point, "clarity" yes, but clarity *of intent* is my goal, which is
different than clarity of coding in the fewest amount of characters a la C.
I'm no great believer of "self-documenting" code, but using final helps say
"this name is not a variable, it is a constant".
Gary
> 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
>
>
--
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
