Re: Should a String-variable be initiated with null or ''

Discussion in 'Java' started by Chris Smith, Aug 15, 2003.

  1. Chris Smith

    Chris Smith Guest

    Morten Simonsen wrote:
    > My collegaue and I have discussed whether a String-variable should
    > be initiated as null or '' (in the case where a value is absent):


    Depends on what you want the string to represent. Null and the empty
    String mean different things. The two alternatives aren't there so you
    can argue about a universal standard, but rather so that you can use
    each when it's appropriate. Furthermore, it's worth considering if you
    should "initialize" the variable at all.

    A null reference represents the absence of an object. If you have a
    variable of type String, but there is no sensible String it could refer
    to, then the variable should be set to null. The empty String is used
    when there is a sensible value, but it just happens to not contain any
    characters.

    In the case of local variables, though, initialization before there is a
    meaningful value is a very bad idea. You should just declare the String
    as:

    String s;

    That gives the compiler the opportunity to tell you whether that
    variable is usable or not. You will then be told if you try to use the
    variable before it has a sensible value. Giving the variable any value
    (even null) before it has a sensible one amounts to sabotaging the
    compiler's perfectly reasonable checks for definite assignment, and just
    opens the door for bugs that should have been caught in the compile.

    Your reasons:

    > 1. Consistency: It is possible to always use and rely on the the
    > A-alternative in your programming.


    For this to matter, you have to actually be using the String. If you're
    using it, then you have some expectations about its behavior. You
    should pick the alternative that matches your expectations. If you're
    not using the String, then why do you care (for consistency, or any
    other reason) what it contains? You'll give it a meaningful value, I
    hope, before you do use it.

    > 2. '' is hardly any supported standard in Java for representing null.


    Well, no. Null is the way to represent null in Java. "" is the way to
    represent the empty string. (Incidentally, '' is simply an illegal
    sequence of characters, and doesn't represent anything.) That should go
    without saying. The problem, though, is that you're trying to
    standardize on one of null or the empty String when both have their
    place.

    Your "colleague"'s reasons:

    > 1. Fewer NullPointerExceptions


    This should be immediately discarded. If you try to dereference the
    object, then the case you mentioned (i.e., there is no real value) is
    not applicable. The idea of trying to be "safe" by avoiding the
    NullPointerException is silly. That exception helps you, by letting you
    know during testing that you've made an inappropriate assumption about
    the value of the variable. If you initialize the variable to a non-null
    value, then you just get logic errors, which may or may not be clearly
    reported during testing.

    Basically, NullPointerException is good. It prevents you from making a
    bigger mistake. I don't understand why so many people are afraid of
    exceptions. (Of course, even better than NullPointerException is a "The
    variable 'x' may not be definitely assigned" at compile-time).

    > 2. In many cases (imagine an object of personal information: address, name,
    > zip-code and
    > so on) you will print the contents of an object. In the print-context the
    > '' is better than
    > null, so that in this case the null-value has to be treated specially.


    Again, if you're printing it, then it has a value that you care about.
    In that case, use the value that matches your expected behavior (i.e.,
    the empty String if you want it to appear empty when printing it.)

    > We agreed that the alternative which "won" the support of the java community
    > would be the preferred one in our company.


    Well, too bad I'm complicating things by telling you that it's
    ridiculous to designate the value of a variable in a company-wide set of
    coding standards. The value should be what makes sense for the code you
    are writing.

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

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Aug 15, 2003
    #1
    1. Advertising

  2. "Chris Smith" <> skrev i melding
    news:...
    > Morten Simonsen wrote:
    > > My collegaue and I have discussed whether a String-variable should
    > > be initiated as null or '' (in the case where a value is absent):

    >
    > A null reference represents the absence of an object. If you have a
    > variable of type String, but there is no sensible String it could refer
    > to, then the variable should be set to null. The empty String is used
    > when there is a sensible value, but it just happens to not contain any
    > characters.


    I think I can agree upon that.

    > In the case of local variables, though, initialization before there is a
    > meaningful value is a very bad idea. You should just declare the String
    > as:
    >
    > String s;
    >
    > That gives the compiler the opportunity to tell you whether that
    > variable is usable or not. You will then be told if you try to use the
    > variable before it has a sensible value. Giving the variable any value
    > (even null) before it has a sensible one amounts to sabotaging the
    > compiler's perfectly reasonable checks for definite assignment, and just
    > opens the door for bugs that should have been caught in the compile.


    But isn't "String s;" == String s = null;"? From the compilers perspective?
    If
    it is as you say I would change my proposal to always initiate a String as
    "String s;".

    > Your reasons:
    >
    > > 1. Consistency: It is possible to always use and rely on the the
    > > A-alternative in your programming.

    >
    > For this to matter, you have to actually be using the String. If you're
    > using it, then you have some expectations about its behavior. You
    > should pick the alternative that matches your expectations. If you're
    > not using the String, then why do you care (for consistency, or any
    > other reason) what it contains?


    [....]

    > Well, too bad I'm complicating things by telling you that it's
    > ridiculous to designate the value of a variable in a company-wide set of
    > coding standards. The value should be what makes sense for the code you
    > are writing.



    At this point I think you oversimplify a little, because it is not uncommon
    that the same object maybe used in various ways and different context,
    it may also be that the same object sometimes are fully populated and
    at other times partially populated. A good example would be the object
    Customer. Often you would just be interested in the name, other times
    the address or some customer-company-relation-information (nice word:).
    If we acknowledge that the use of the object may vary, then we are halfway.
    Because the usage varies, then the popuation also may vary usually because
    of performance issues. Furthermore, the person which are responsible for
    populating an object (or creating it) are not necessarily the same person
    which
    uses it. Lastly: when populating the object, a variable may be populated
    with
    a "null" (s = rs.getString("MIDDLE_NAME");) In this situation I find very
    complicated to say what is to be expected of the usage of the object AND how
    the object in fact is populated when using the ""-variant. In those cases
    where I care whether a value is absent or not, I usually end up with this:

    if (s != null && !s.equals("")) ...

    or I can search through code to find out how s is initiated, which takes
    more
    of my time. That is why I think consistency is a good reason for the
    "null-alternative",
    because I will never have doubts about the variable: It is either null or
    something else.
    If is is something else, I will probably not encounter "", because it is not
    used
    anyware in the code (or in the java-library). The only reason I should need
    "" then,
    is when I will print it. That should be handled in the printing-code.

    Morten Simonsen
    Morten Simonsen, Aug 19, 2003
    #2
    1. Advertising

  3. Chris Smith

    Chris Smith Guest

    Morten Simonsen wrote:
    > > In the case of local variables, though, initialization before there is a
    > > meaningful value is a very bad idea. You should just declare the String
    > > as:
    > >
    > > String s;
    > >
    > > That gives the compiler the opportunity to tell you whether that
    > > variable is usable or not. You will then be told if you try to use the
    > > variable before it has a sensible value. Giving the variable any value
    > > (even null) before it has a sensible one amounts to sabotaging the
    > > compiler's perfectly reasonable checks for definite assignment, and just
    > > opens the door for bugs that should have been caught in the compile.

    >
    > But isn't "String s;" == String s = null;"? From the compilers perspective?


    No.

    Instance and static fields have a default value, which is null for
    reference variables. An instance or static field that is not explicitly
    assigned will start out as null. That's not the same as saying that the
    declaration is equivalent to "String s = null" because of ordering
    issues (that latter will assign s to null as a default value, and then
    reset it to null again after the superclass constructors have completed,
    whereas the former just assigns null as a default value), but it's
    close.

    For local variables, the situation is quite different. A local variable
    that's declared without an explicit value can not be legally used until
    it is definitely assigned a value. It doesn't have a default value of
    any kind. To see what I mean, try compiling this code:

    class DefiniteAssignmentTest
    {
    public static void main(String[] args)
    {
    String s;
    System.out.println(s);
    }
    }

    > If it is as you say I would change my proposal to always initiate a
    > String as "String s;".


    I'm assuming that you would always do so unless there's a meaningful
    value to give the variable. That would be a good idea. It's never a
    good idea to initialize a variable when you don't intend to depend upon
    that value, and it's even worse when the variable is local because
    you're essentially declining valuable help from the compiler.

    > > Well, too bad I'm complicating things by telling you that it's
    > > ridiculous to designate the value of a variable in a company-wide set of
    > > coding standards. The value should be what makes sense for the code you
    > > are writing.

    >
    > At this point I think you oversimplify a little, because it is not uncommon
    > that the same object maybe used in various ways and different context,
    > it may also be that the same object sometimes are fully populated and
    > at other times partially populated.


    Maybe we're thinking about different things, but I'd characterize a form
    of programming where objects hold rather arbitrary sets of data and not
    all of their fields are valid at a given time as rather sloppy and
    haphazard. I'd stay as far away from such code as possible.

    On the other hand, it's fairly reasonable in a few select situations to
    use fields that initially don't have contents, and fill them in lazily.
    If that's what you're asking for, I agree that null is appropriate.
    However, the key point is that you've specifically and quite
    intentionally designed the object to be a lazy-loading cache for values
    that would otherwise be expensive to retrieve or calculate. You have
    intentionally chosen to use null because there's an absence of an
    object, and that's what null means. That's a rather specific and
    intentional usage, which would generally be relatively rare, and doesn't
    seem to be what you were asking about.

    Instead, you seem to be looking for some kind of common declaration for
    all variables, that you can use by default; without thinking, as it
    were. If so, the very fact that you're writing code to access the value
    of a variable, and you haven't intentially placed a value there, is a
    warning sign that you ought to be doing something differently.

    > A good example would be the object
    > Customer. Often you would just be interested in the name, other times
    > the address or some customer-company-relation-information (nice word:).
    > If we acknowledge that the use of the object may vary, then we are halfway.
    > Because the usage varies, then the popuation also may vary usually because
    > of performance issues.


    Have you actually checked to ensure that this is worthwhile. Retrieving
    extra fields from a database when you're already doing the query is
    rarely an insurmountable performance obstacle. In any case, it's sure
    to make your code many times more difficult to understand.

    More importantly, if this is the reason for not initializing the
    variables, then null seems to be a reasonable value... BUT, why is that
    null value ever getting outside the implementation of this class? You
    just said that the fields you're not retrieving aren't used, but then
    you're concerned about what value to expect when using them?

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

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Aug 19, 2003
    #3
  4. "Morten Simonsen" <> writes:

    >
    > But isn't "String s;" == String s = null;"? From the compilers perspective?
    > If
    > it is as you say I would change my proposal to always initiate a String as
    > "String s;".
    >

    Only for a class member variable. Variables which are local to a
    method are not given a default initialisation. This is why this will
    give you a error.

    public void doSomething() {
    String x;
    int y = x.length();
    }

    Something along the lines of 'variable x might not have been initialised.'

    --
    Pick a different user name to email me.
    Andrew Cowper, Aug 19, 2003
    #4
  5. Chris Smith

    rkm Guest

    Didn't see the whole thread, so maybe someone mentioned this...

    In the case where you are putting the values in a db, you
    will see methods for assigning the different types of java
    values to db fields, such as setInt(x,y), setFloat(x,y),
    whatever.

    What I find annoying to have to write is
    if( theString == null)
    setNull( param1 );
    else
    setString( param1, theString);

    So to avoid that, I init my strings with "",
    then I never have to use setNull. Of course I have to be
    sure my string never reverts to null, and so far that's held up.

    The other advantage to this is that once the string's in the
    db, I don't have write special query joins to account for
    the case where a value is null because I know all the
    strings will have a value, even if it's the empty string
    value. Null values require special treatment, which is just
    more annoying code to have to write.

    Rick
    rkm, Aug 20, 2003
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dan
    Replies:
    5
    Views:
    2,850
    bruce barker
    Dec 1, 2003
  2. Srinivasa Raghavan Sethuraman
    Replies:
    0
    Views:
    548
    Srinivasa Raghavan Sethuraman
    Jun 30, 2004
  3. Guest
    Replies:
    2
    Views:
    2,007
    Steven Cheng[MSFT]
    Aug 18, 2005
  4. Starwynd
    Replies:
    2
    Views:
    1,561
    Starwynd
    Jan 23, 2004
  5. Replies:
    1
    Views:
    1,420
    Ivan Villanueva
    Jun 3, 2005
Loading...

Share This Page