Prev: neutral American English pronunciation of "Math.sin"
Next: Work at Home - Earn 50,000 Weekly Without Investment Its Not A Fake, 100% Earning Guarantee
From: david.karr on 13 Mar 2010 11:37
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?
From: Mike Schilling on 13 Mar 2010 11:50
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*".




From: david.karr on 13 Mar 2010 17:15
On Mar 13, 8:50 am, "Mike Schilling" <mscottschill...(a)hotmail.com>
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).
From: Lothar Kimmeringer on 13 Mar 2010 18:36
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: spamfang(a)kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
From: Mike Schilling on 13 Mar 2010 21:19
Arne Vajh�j wrote:
> 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.

Sure do. Perhaps think of the example as realizing after the fact that the
empty string is a valid value, but non-alphanumeric strings never will be.


 |  Next  |  Last
Pages: 1 2
Prev: neutral American English pronunciation of "Math.sin"
Next: Work at Home - Earn 50,000 Weekly Without Investment Its Not A Fake, 100% Earning Guarantee