Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Rational argument for not defining string constant for empty string?

Reply
Thread Tools

Rational argument for not defining string constant for empty string?

 
 
david.karr
Guest
Posts: n/a
 
      03-13-2010
So let's say you're working with a developer who has accepted the
wisdom of defining constants for oft-used hardcoded strings. They
then decide that lines like this:

String foo = "";

should instead be:

String foo = StringConstants.EMPTY_STRING;

Assuming you conclude, as I do, that this is going too far, what
rational and logical arguments would you present to convince someone
that doing this is a mistake?
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      03-13-2010
"david.karr" <(E-Mail Removed)> writes:
>So let's say you're working with a developer who has accepted the
>wisdom of defining constants for oft-used hardcoded strings.


It depends on the presumed/expected change structure.

I refactor

... print( "Paris" ) ...
...
... print( "Paris" ) ...

to

paris = "Paris"

... print( paris ) ...
...
... print( paris ) ...

/only if/, whenever the first "Paris" is changed, the
second also needs to change in exactly the same way.

So, constants are not defined for hardcoded strings
but for co-changing entities.

>They
>then decide that lines like this:
>String foo = "";
>should instead be:
>String foo = StringConstants.EMPTY_STRING;


>Assuming you conclude, as I do, that this is going too far, what
>rational and logical arguments would you present to convince someone
>that doing this is a mistake?


Every change costs time (including the time for discussing
it) and has the risk of introducing errors, so there is a
change overhead. We only want to pay the change overhead if
the change brings as an even larger benefit with a
sufficient certainity.

So, when /they/ want to change something, /they/ need to
bring forward reasons for this, making it visible how the
change should have such a benefit with a sufficient
certainity. Then, we can discuss this here.

 
Reply With Quote
 
 
 
 
Mike Schilling
Guest
Posts: n/a
 
      03-13-2010
david.karr wrote:
> So let's say you're working with a developer who has accepted the
> wisdom of defining constants for oft-used hardcoded strings. They
> then decide that lines like this:
>
> String foo = "";
>
> should instead be:
>
> String foo = StringConstants.EMPTY_STRING;
>
> Assuming you conclude, as I do, that this is going too far, what
> rational and logical arguments would you present to convince someone
> that doing this is a mistake?


The point of defining a string constant is to

1. Give the string a meaingful name
2. Make life easier for developers, who can refer to the constant rather
than type the string (especially useful with an IDE)
3. Ensure the string doesn't get mistyped.
4. Allow the string value, if it needs to change, to be changed in one
place.

Inventing a constant that simply means "the empty string" accomplishes none
of these.

1. We already know that "" is the empty string. The name EMPTY_STRING adds
no new information
2. "" is easier to type than the constant
3. There's a very small change of mistyping "".
4. here's no other possible value for StringConstants.EMPTY_STRING

However, if an empty string is being used for some specific purpose, e.g. to
mean "this value is unknown", it would make perfect sense to define

public static final String UNKNOWN_VALUE = "";

1. Anyone reading the program knows that the value is unknown as opposed to
being known to be empty
2. Developers don't have to recall whether unknwn values are empty strings
or nulls
3. More or less the same as 2 in this case
4. If you later decide that "" is a valid value, UNKNOWN_VALUE can be
changed to, say, "*unknown*".




 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      03-13-2010
"Mike Schilling" <(E-Mail Removed)> writes:
>1. We already know that "" is the empty string. The name EMPTY_STRING adds
>no new information


Actually, it holds /less/ information. We do not know its text,
it could be defined as

EMPTY_STRING := "EMPTY_STRING"

or

EMPTY_STRING := "empty"

or so.

 
Reply With Quote
 
david.karr
Guest
Posts: n/a
 
      03-13-2010
On Mar 13, 8:50*am, "Mike Schilling" <(E-Mail Removed)>
wrote:
> david.karr wrote:
> > So let's say you're working with a developer who has accepted the
> > wisdom of defining constants for oft-used hardcoded strings. *They
> > then decide that lines like this:

>
> > * String foo = "";

>
> > should instead be:

>
> > *String foo = StringConstants.EMPTY_STRING;

>
> > Assuming you conclude, as I do, that this is going too far, what
> > rational and logical arguments would you present to convince someone
> > that doing this is a mistake?

>
> The point of defining a string constant is to
>
> 1. Give the string a meaingful name
> 2. Make life easier for developers, who can refer to the constant rather
> than type the string (especially useful with an IDE)
> 3. Ensure the string doesn't get mistyped.
> 4. Allow the string value, if it needs to change, to be changed in one
> place.
>
> Inventing a constant that simply means "the empty string" accomplishes none
> of these.
>
> 1. We already know that "" is the empty string. *The name EMPTY_STRING adds
> no new information
> 2. "" is easier to type than the constant
> 3. There's a very small change of mistyping "".
> 4. here's no other possible value for StringConstants.EMPTY_STRING
>
> However, if an empty string is being used for some specific purpose, e.g. to
> mean "this value is unknown", it would make perfect sense to define
>
> * public static final String UNKNOWN_VALUE = "";
>
> 1. Anyone reading the program knows that the value is unknown as opposed to
> being known to be empty
> 2. Developers don't have to recall whether unknwn values are empty strings
> or nulls
> 3. More or less the same as 2 in this case
> 4. If you later decide that "" is a valid value, UNKNOWN_VALUE can be
> changed to, say, "*unknown*".


Thanks, all good points.

If I were to present this to someone, I think I would put some of your
justification for the "meaningful name" point back into the statement
itself. It's important to qualify that the "meaningful name" is of no
added value if it doesn't provide more information than the value it's
defined to represent (and to Stefan's point, perhaps even less than
zero if it's not completely unambiguous what value the constant
represents).
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      03-13-2010
On Sat, 13 Mar 2010 08:37:09 -0800, david.karr wrote:

> should instead be:
>
> String foo = StringConstants.EMPTY_STRING;
>

Inventing something like a StringConstants class causes problems on just
about every level. A constant is only meaningful within some context, so
should be defined in a superclass or class that is logically part of the
context and is named appropriately. The constant name should reflect is
meaning within the context.

> Assuming you conclude, as I do, that this is going too far, what
> rational and logical arguments would you present to convince someone
> that doing this is a mistake?
>

The person proposing this idea is probably an MBA or related organism and
so won't understand logic or rational arguments.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Lothar Kimmeringer
Guest
Posts: n/a
 
      03-13-2010
Stefan Ram wrote:

> Actually, it holds /less/ information. We do not know its text,
> it could be defined as
>
> EMPTY_STRING := "EMPTY_STRING"
>
> or
>
> EMPTY_STRING := "empty"
>
> or so.


That would be a new entry for the dailywtf. Best until now was
enum Bool = {True, False, FileNotFound}


Regards, Lothar
--
Lothar Kimmeringer E-Mail: http://www.velocityreviews.com/forums/(E-Mail Removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      03-13-2010
On 13-03-2010 11:37, david.karr wrote:
> So let's say you're working with a developer who has accepted the
> wisdom of defining constants for oft-used hardcoded strings. They
> then decide that lines like this:
>
> String foo = "";
>
> should instead be:
>
> String foo = StringConstants.EMPTY_STRING;
>
> Assuming you conclude, as I do, that this is going too far, what
> rational and logical arguments would you present to convince someone
> that doing this is a mistake?


It does not provide any value. "" is readable and will never
change value.

This is just code clutter.

One of the most important aspects of good rules is to
know when they apply and when they do not apply.

Note that:

String foo = "";

is better than:

String foo = StringConstants.EMPTY_STRING;

but in some contexts it would be even better to use:

String foo = FOO_DEFAULT;

because "" wil never change value, but the default value of
foo could change.

Arne


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      03-13-2010
On 13-03-2010 11:50, Mike Schilling wrote:
> david.karr wrote:
>> So let's say you're working with a developer who has accepted the
>> wisdom of defining constants for oft-used hardcoded strings. They
>> then decide that lines like this:
>>
>> String foo = "";
>>
>> should instead be:
>>
>> String foo = StringConstants.EMPTY_STRING;
>>
>> Assuming you conclude, as I do, that this is going too far, what
>> rational and logical arguments would you present to convince someone
>> that doing this is a mistake?

>
> The point of defining a string constant is to
>
> 1. Give the string a meaingful name
> 2. Make life easier for developers, who can refer to the constant rather
> than type the string (especially useful with an IDE)
> 3. Ensure the string doesn't get mistyped.
> 4. Allow the string value, if it needs to change, to be changed in one
> place.
>
> Inventing a constant that simply means "the empty string" accomplishes none
> of these.
>
> 1. We already know that "" is the empty string. The name EMPTY_STRING adds
> no new information
> 2. "" is easier to type than the constant
> 3. There's a very small change of mistyping "".
> 4. here's no other possible value for StringConstants.EMPTY_STRING


Very well explained.

> However, if an empty string is being used for some specific purpose, e.g. to
> mean "this value is unknown", it would make perfect sense to define
>
> public static final String UNKNOWN_VALUE = "";
>
> 1. Anyone reading the program knows that the value is unknown as opposed to
> being known to be empty
> 2. Developers don't have to recall whether unknwn values are empty strings
> or nulls
> 3. More or less the same as 2 in this case
> 4. If you later decide that "" is a valid value, UNKNOWN_VALUE can be
> changed to, say, "*unknown*".


Even though I completely agree with the point, then I am not sure
that I like the example.

Valid values having special semantics can create a lot of problems.

Arne
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      03-14-2010
Stefan Ram wrote:
>> Actually, it holds /less/ information. We do not know its text,
>> it could be defined as
>>
>> EMPTY_STRING := "EMPTY_STRING"
>>
>> or
>>
>> EMPTY_STRING := "empty"
>>
>> or so.


Lothar Kimmeringer wrote:
> That would be a new entry for the dailywtf. Best until now was
> enum Bool = {True, False, FileNotFound}


"This page intentionally left blank."

--
Lew
This brain intentionally left blank.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why defining a constant in a method is not allowed but usingself.class.const_set is allowed? I├▒aki Baz Castillo Ruby 13 05-01-2011 06:09 PM
concatenate a constant to constant string using macros sinbad C Programming 7 06-19-2008 05:28 PM
defining a flag-dependent constant valentin tihomirov VHDL 3 11-28-2004 04:15 AM
"Non-constant" constant can't be used as template argument Martin Magnusson C++ 2 10-08-2004 08:41 AM
defining or not defining destructors johny smith C++ 8 07-02-2004 08:51 AM



Advertisments