good practice to initalize all instance variables with type String to emptry string??

[Matt]

Is it a good practice to initalize all instance variables with
type String to emptry string?

#1 approach:
public class A
{ private String name = "";
private String address ="";
//etc...
}

rather than

#2 approach:
public class A
{ private String name;
private String address;
//etc...
}

When I read Java books, the examples don't usually do #1 approach.
The problem is if we don't initialize to empty string, when we call
the getter method of that instance variable, it will return null.

Please advise. Thanks!!

 

[Lee Weiner]

When I read Java books, the examples don't usually do #1 approach.
The problem is if we don't initialize to empty string, when we call
the getter method of that instance variable, it will return null.

And...?

If an instance variable hasn't been assigned a value, isn't null a good signal
that it has never been set?

Lee Weiner
lee AT leeweiner DOT org

 

[Chris Smith]

#1 approach:
public class A
{ private String name = "";
private String address ="";
//etc...
}

When I read Java books, the examples don't usually do #1 approach.
The problem is if we don't initialize to empty string, when we call
the getter method of that instance variable, it will return null.

Repeat ten times: "The compiler is my friend. The VM is my friend."

You're considering a coding convention that appears designed to prevent
errors, but not to produce correct code. That's a very bad combination.
If there's one thing worse than broken code, it's broken code that
silently screws up your life without a single error message.

There's no way of avoiding it: a variable needs to be assigned a useful
value before it's used. If you don't assign it a useful value, then you
can't write useful code that uses that value. Garbage in, garbage out;
code will be broken regardless of which specific useless value you
assigned. It's better for broken code to get back a null than an empty
String, because using the null reference will cause an error message and
let you know that something is amiss, whereas the empty string is more
likely to break something silently.

Of course, that's if you admit the possibility of error. If you never
make mistakes, then why bother typing ' = ""' at the end of your String
declarations anyway.

(And, of course, it goes without saying that if the empty String is a
reasonable initial value, for example if the String will have things
appended to it over time and needs to start out blank, then of course
you should intialize it to an empty String; but specifying that
initialization as any kind of a default is still a mistake.)

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Kevin McMurtrie]

Is it a good practice to initalize all instance variables with
type String to emptry string?

#1 approach:
public class A
{ private String name = "";
private String address ="";
//etc...
}

rather than

#2 approach:
public class A
{ private String name;
private String address;
//etc...
}

When I read Java books, the examples don't usually do #1 approach.
The problem is if we don't initialize to empty string, when we call
the getter method of that instance variable, it will return null.

Please advise. Thanks!!

#1 is perfectly good style if the getter is defined as returning an
empty string when there's no set value. This technique is common for
some GUI beans where the user should be presented with nothing rather
than the word "null." In other cases there needs to be differentiation
between null and an empty string, so you'd initialize the variables to
null.

And finally, member variables that MUST be set should be declared as
final. You'll get a compiler error if you accidentally create a new
constructor that does not set them.

 

[Roedy Green]

In other cases there needs to be differentiation
between null and an empty string, so you'd initialize the variables to
null.

see http://mindprod.com/jgloss/void.html
for a long discussion of the problem.