Is it worth keeping constants for primitives in Java?

Question

My question is related to Is making an empty string constant worth it?.

I know constants should have meaningful names, but is there any benefit in extracting primitive values like ints in Java in a Constants file like:

public final static int ZERO = 0;

to use as general-purpose constants and keep reusing it like Constants.ZERO in your code-base or better use the literal value of 0?

What about general-purpose booleans? i.e.

public static final boolean TRUE = true;
public static final boolean FALSE = false;

Answer 1

For the constants you are defining, there's no reason for them because there is no extra meaning. The literals 0, true, and false already have their meaning.

Constants would be worth creating if there is some extra meaning to attach to those values, such as:

public static final int SUCCESS = 0;
public static final boolean DEBUG = true;

There is meaning behind these values, and it's possible that they may change:

public static final int SUCCESS = 1;
public static final boolean DEBUG = false;

which would make it easier to change the values than changing lots of literals in the program.

If the values have meaning beyond their literal values, and if they could change, then creating constants is worth the effort.

Answer 2

There are two very good reasons for naming constants. The best reason is to clarify code by naming the constant (Pi, EarthDiameter, SpeedofLight, AvagadroNumber, etc) rather than refer to the value directly. Another is to name quantities that are considered constant, but may change due to changing specifications (examples: MAX_CHILD_THREADS, BtreeRadix). But placing the definition of these constants in one location, revising their values to meet future needs becomes easier.

Providing names for the constants you mention (0,1,true,false, etc) already have their meaning. Naming the constant 0 to be Zero really adds nothing. There is a small value to naming the empty string "", as you are providing some additional meaning -- not just that the literal is "", but that your meant to say the EmptyString.

Many systems define numeric values to have meaning, such as the Linux/Unix errno.h, providing systemwide meaning to specific integers. Thus, there is value to definitions such as,

public static final int SUCCESS = 0;
public static final int EPERM = 1; // Operation not permitted
public static final int ENOENT= 2; // No such file or directory
public static final int ESRCH = 3; // No such process
public static final int EINTR = 4; // Interrupted system call

Because using those names gives clarity to the intention of the developer.

Answer 3

If it makes your program easier to understand or maintain, yes. Otherwise, no.

The HotSpot VM probably complies your code to the same machine code either way.

And by the way, Boolean.TRUE and Boolean.FALSE already exist.

Answer 4

It would be more useful to have a context-specific name to the constant 0 (like NUM_EXCEPTIONS_TO_TOLERATE) than a simple ZERO as it wouldn't convey much.

As for booleans, the variable name would convey the context and so doesn't make much sense to define them as constants.

If you are worried about space, I would think it as too much of premature optimization.

Answer 5

Boolean constants already exist Boolean.TRUE and Boolean.FALSE.

I only use constants like that if its for a a magic number that hardcoding it in the code isn't obvious then.

private static final int SECS_PER_DAY = 86400;

so ZERO doesn't make much sense by itself.

Answer 6

I doubt that ZERO, FALSE or TRUE will ever change their value. Moreover FALSE and TRUE are defined in the Boolean class (but not as primitives).

Answer 7

Use constants like that to avoid having "magic numbers" littering your code. That is to say that code readability is King, so SOME_SIGNIFICANT_NUMBER is better than an apparently random 33, or 57, or 98, or whatever.

Also maintenance may be easier if you reference it in muliptle places - i.e you won't have to change 100 literals if they all use the same constant.

Answer 8

It all goes back to code readability. A good metric of that - number of "WTF?!?!" per minute by a person reading your code.

Bad use of constants - documenting self-evident things:

// yeah, that we have bigger problems if that changes...
public static final String WORLD_WIDE_WEB_PREFIX = "www";

Another instance - substituting a constants where a straight value would make just as much sense:

// to be used in exactly 1 place
private static final int RETRY_COUNT = 3;
// ...
// ... 480 lines later ...
// ...
public int getRetryCount() {
  // what's the value of this thing again?
  return RETRY_COUNT;
}

With the previous example however, if you're planning to use the value of 3 in more than a single place, a constant is better - it will guarantee that all references of that number are in sync (you change it from 3 to 5, they all change)

On the other hand,

// what's 143?!?! where do I go looking for what it means?!?!
complexPart.setType(143);