Too many constants?

Question

Is there such a thing as too many constants in a project? What are some general rules of thumb about where the use of constants starts to become inappropriate and should be refactored? Perhaps moving some of these values into a model tier, or configuration files, etc.

A concrete example. Using the pureMVC framework for Actionscript/Flex projects. This framework relies on the Facade pattern to store a central configuration for the application. Lots of constants can be declared in this Facade and most of the constants are mapped to commands. But in other cases there can be non command based constants. For a non trivial app there can be a lot of constants in the Facade.

The constants are really convenient, because they allow you search throughout your project for when a particular command or value is used. But when is the amount and type of use of constants going too far?

What is an inappropriate use of a constant?

Answer 1

What is an inappropriate use of a constant?

imho, never. Constants raises maintainability and readability. They also encapsulate change. I cannot see drawbacks in using constants in your code.

Answer 2

Well I don't think there is any rule to tell us how many constants are too much in a project, is a bit like asking how many for loops are too much in a project... The question you may want to ask yourself are...

1. Do I need all this constants?
2. Is there any repetition in the constants I can get rid off?
3. Are they best represented as constants or should I represent them as something different?

[EDIT in response to Gordon's comment: "Any examples of where #3 would apply?"]

Let's see this Java example, imagine you have the following:

static final String ICECREAM_VAINILLA = "vainilla"; 
static final String ICECREAM_STRAWBERRIE = "strawberrie"; 
static final String ICECREAM_LEMON = "lemon"

Maybe it would be a good idea to use some other representation, and that will depend on the language, for instance in java you can use enums..

enum IceCreamFlavor
{ 
    VAINILLA, 
    STRAWBERRIE, 
    LEMON
}

You can also use a dependency injection framework as SPRING, XML files

Answer 3

If you have many constants, you should group them, either with namespaces, or with name prefixes. Per group, there cannot be too many constants - e.g. if you have a group of constants denoting commands, it's fine if it grows, as long as it only contains commands. Anybody looking for a constant would then first find the group, then search for the constant within the group. Some programming languages support an enumeration data type for that.

Answer 4

If the constants are for different groups of functionality, you may find you're introducing cyclic dependencies between layers by having them all in one type. I avoid having a single "constants" class for this reason, instead look to put the constants in the relevant interface/type, so the types that are likely to use the constant already have a reference to the owning type.

As far as an absolute limit, there isn't one, but if you've got a shed load, it might indicate you need to refactor your code to separate the concerns

Answer 5

It some applications (say when they represent the hundreds of measurements that parameterize the layout of a particle physics experimental hall), you might want to replace them with a run-time parameter input arrangement.

It saves a recompile to simulate a different experiment.

Or not, because it might reduce the number of optimization the compiler can apply.

Decisions, decisions.

Answer 6

There can't be to much constant. I would use another measurement. If you define the constant and then never touch it again while adding further changes and deploying to different machines it is a good constant. If there constants that are often changed maybe dependent on the machine/operating system the application is running then you should think about moving this constant in a configuration file.

Answer 7

I always use constants for any value that is meaningful or that is used by the program.

For example, if the value is a string "RH" that would be stored into a database, I might create a constant STATUS_RH for that. This ensures that it can be easily changed, and that only correct values are used since there will be no constant defined for an incorrect value.

I also do this for error messages, but this isn't nearly so critical since the program will work regardless of whether I output "incorrect value for foobar" vs. "bad val for foobar".

Answer 8

There's a handful of magic values that you probably shouldn't bother using constants for when they're used for generic language purposes. This mostly comes down to numbers such as 0, 1 and -1.

For example, a typical for loop starts at 0, yet isn't made any clearer if that 0 is replaced by a constant.

edit

Constants are fine and I wouldn't be bothered by the number of them. However, I would be bothered if constants were confused with configuration settings and text resources.

Messages that are shown to the user in one form or another should almost always be treated as external resources so that they can be translated independently.

Text that contains magic values that may need to be changed after installation is configuration, and it almost always belongs in an XML file, on the database or somewhere else that's external and easily changed.

Answer 9

There is no such thing as too many constants. There are, however, such things as:

• constants that shouldn't exist, e.g. NUMBER_OF_OBJECT_RETURNED_BY_THIS_SINGLETON).
• too many constants in one place: I add a new menu item, Bob adds a new XML tag -> code merge required.

Answer 10

I agree that there is no such thing as too many constants - as long as they are actually meaningful. Don't do like a guy I work with that has defined Constants::One = 1, Constants::Ten = 10, etc. That doesn't encapsulate change very much.