Is making an empty string constant worth it?

Question

I have a co-worker that swears by

//in a singleton \"Constants\" class
public static final String EMPTY_STRING = \"\";

in a constants class

Answer 1

I don't like either choice. Why not if (otherString.length() == 0)

Edit: I actually always code

if (otherString == null || otherString.length() == 0)

Answer 2

The same argument comes up in .NET from time to time (where there's already a readonly static field string.Empty). It's a matter of taste - but personally I find "" less obtrusive.

Answer 3

David Arno states: -

Ironically the whole point of constants is to make them easily changeable

This is simply not true. The whole point of constants is reuse of the same value and for greater readability.

It is very rare that constant values are changed (hence the name). It is more often that configuration values are changed, but persisted as data somewhere (like a config file or registry entry)

Since early programming, constants have been used to turn things like cryptic hex values such as 0xff6d8da412 into something humanly readable without ever intending to change the values.

const int MODE_READ       = 0x000000FF;
const int MODE_EXECUTE    = 0x00FF0000;
const int MODE_WRITE      = 0x0000FF00;
const int MODE_READ_WRITE = 0x0000FFFF;

Answer 4

I much prefer seeing EMPTY_STRING.

It makes it english. "".equals 'reads' differently than EMPTY_STRING.equals.

Answer 5

Well, I could guess too, but I did a quick test... Almost like cheating...

An arbitrary string is checked using various methods. (several iterations)

The results suggests that isEmpty() is both faster and indeed more readable; If isEmpty() is not available, length() is a good alternative.

Using a constant is probably not worth it.

"".equals(someString())      :24735 ms
t != null && t.equals("")    :23363 ms
t != null && t.equals(EMPTY) :22561 ms
EMPTY.equals(someString())   :22159 ms
t != null && t.length() == 0 :18388 ms
t != null && t.isEmpty()     :18375 ms
someString().length() == 0   :18171 ms

In this scenario;

"IAmNotHardCoded".equals(someString())

I would suggest defining a constant in a r e l e v a n t place, since a global class for all constants really sucks. If there is no relevant place, you are probably doing something else wrong...

Customer.FIELD_SHOE_SIZE //"SHOE_SIZE"

Might be considered a relevant place where as;

CommonConstants.I__AM__A__LAZY__PROGRAMMER // true

is not.

For BigIntegers and similar thing, I tend to end up defining a final static locally; like:

private final static BigDecimal ZERO = new BigDecimal(0);
private final static BigDecimal B100 = new BigDecimal("100.00");

Thats bugs me and wouldn't it be nice with some sugar for BigInts and BigDecimals...

Answer 6

1. yes--it offers no benefit.
2. depends on what you're used to, I'm sure.
3. No, it's just a constant--not an abuse.