Prev: StrutsTestCase and Netbeans
Next: Centralizing instantiation?
From: Rhino on 25 May 2010 16:37
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?

--
Rhino
From: Arne Vajhøj on 25 May 2010 16:48
On 25-05-2010 16:37, 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 strongly favor readability here. The extra overhead of something
getting initialized twice should be minimal or zero if the JIT
compiler optimizes it away.

Basically I would either initialize all the fields inline or
initialize no fields inline and assign values to all of them
in the constructor.

This ensures that:
- everything is initialized the same place
- everything has an explicit initialization

This is more readable in my opinion.

Arne


From: Daniel Pitts on 25 May 2010 17:09
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/>
From: Arved Sandstrom on 25 May 2010 17:14
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 am in agreement with Arne here. Generally speaking I want to
understand not only when member and local variables are initialized but
also every time they are updated; initialization to me is not
intrinsically noteworthy, it's just the first assignment of value, but
often not the last.

In order to more clearly understand where (and by what) variables are
updated, readability is important. Restricting access and scope (and
using final) is important. Using setters even when you can access the
variable directly is often preferable.

So, generally speaking, if you can easily keep track of variable
assignments, including initialization, which means readable and
maintainable assignments, you've answered your question. There are no
magic rules for this otherwise.

AHS
From: Jim Janney on 25 May 2010 17:53
Rhino <no.offline.contact.please(a)example.com> writes:

> 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?

"Just to be sure it has some kind of value" is a very weak reason for
initializing a variable. If you don't have a meaningful value for a
variable, throwing in a meaningless one just makes the code harder to
read. At the same time, most declarations should be initialized. How
is this possible? It's simple: don't declare a variable until you're
ready to give it a value. For example, here is a method from the
Apache Commons string utils:

public static String deleteWhitespace(String str) {
if (str == null) {
return null;
}
int sz = str.length();
StringBuffer buffer = new StringBuffer(sz);
for (int i = 0; i < sz; i++) {
if (!Character.isWhitespace(str.charAt(i))) {
buffer.append(str.charAt(i));
}
}
return buffer.toString();
}


You could move sz, buffer, and i to the top of the method and
initialize them with make-believe values, but it wouldn't be an
improvement.

There *are* times when you have to give a variable a value just to
make the compiler happy. Normally this is a sign that you should
rewrite the code, but sometimes you can't (for example, when
implementing a simple FSM). When I have to write a bogus
initialization I usually flag it with a comment.

--
Jim Janney
 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: StrutsTestCase and Netbeans
Next: Centralizing instantiation?