Re: Initializing Variables
On 5/25/2010 1:37 PM, Rhino wrote:
I've received some criticism recently with regards to the approach I use to
initializing variables so I'd like to throw this issue out to the whole
group so that I can learn more about the pros and cons of the approach I am
using....
Basically, I initialize pretty much every variable as I declare it, just to
be sure it has some kind of value right away. That initial value is
typically a zero for a number or a null for an object. Some recent
criticism questioned this practice so I thought I'd review some of the
material that helped get me in that habit in the first place.
The Java Tutorial, specifically
http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html,
says that, although non-local variables always get a default value anyway,
relying on that "is generally considered bad programming style". They also
point out that local variables are never assigned values in advance and
will cause compile-time errors if an unitialized variable is accessed.
Now, the Java Tutorial is aimed at Java beginners so this particular advice
may not be appropriate for people with more experience. I consider the
experts on this group a pretty advanced bunch so how do you feel about this
advice?
I generally try to declare every field and local variable as "final" if
possible. In other words, I want my value to be initialized exactly
once. This doesn't always work with dependency injection frameworks,
but I use that as the guideline.
If a variable *can* be set more than once, you have a few things to
worry about.
First is, can I provide a sensible default value. The null value is
language provided default for reference fields, but often times there is
a better default value. One pattern I like to use is the "null object
pattern" <http://en.wikipedia.org/wiki/Null_Object_pattern>. This
obviates the need for null checks in many places, especially if you have
a setter method which replaces null with your null-object.
The second thing to worry about is consistency. If a variable can have
multiple values throughout its lifetime, then it becomes more
complicated understanding which value you are getting. Sometimes the
knowledge of "which" isn't necessary for understanding, but other times
it is. If you have a complex external algorithm which queries your
object several times, it could cause problems if the underlying data is
switched out from under it.
The third thing is there are concurrency concerns with non-final
references. I won't go into details, but Java Concurrency in Practice
can help:
<http://virtualinfinity.net/wordpress/technical-book-recommendations/java-concurrency-in-practice/>
So in general, I think initializing with a value you never expect to get
used is an error. If possible, instead of initializing, you should try
to find a way to cause a compiler error. Using final and local variables
are good for this. If you expect it to be used before it is
re-initialized, find a sensible default value. If you can't do either,
then at the very least document that fact very well, and throw
informative runtime errors if the value isn't initialized properly.
Also, if you have a complicated code-path necessary for determining the
initial value, try moving that into a private method which returns the
value. That can make it simpler to understand.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>