Is a constant name related to its current value an anti-pattern? [closed]

Question

For example, suppose I have a string constant like this:

const TITLEBAR_MESSAGE="Welcome back, %USERNAME%!";

I think it is more readable when it is named as

const WELCOME_BACK_USERNAME="Welcome back, %USERNAME%!";

because I don't need to move to the definition of TITLEBAR_MESSAGE to see what is the string context, also I don't need to remember that "TITLEBAR_MESSAGE" is mapped to "Welcome back,xxx" currently.

I know it would less maintainable when the string is changed because I also need to change its name. But code is read more than write, right? I think the latter naming is more straightforward so that other team members don't need to know what "TITLEBAR" is.

Similar cases also appears for colour constants:

const COLOR_SOME_UI=[32,0,0];

Which I think:

const COLOR_DEEP_RED=[32,0,0];

is more straightforward (when there is just a few color only) as other team member doesn't need to know what "SOME_UI" is. So my question is, is a constant name related to its current value an anti-pattern?

Answer 1

It entirely depends on whether it is a constant and won't likely change or if it is a constant which is symbolic or representative of something else and therefore may change.

An example of a constant which won't likely change is:

const PI=3.1415926
const RED=[255,0,0]

In this case, call it as it is. It represents the value of PI, not some arbitrary float.

An example of a constant which is symbolic or representative of something else is:

const WELCOME_MESSAGE="welcome.user"
const CONNECT_URL="jdbc:sqlserver://server:1433;databaseName=AdventureWorks"

This is not the message itself, but rather a key for looking up the message. If later you should decide that the key would be better written "user.welcome", you can change the constant in your program, and WELCOME_MESSAGE is equally valid and therefore doesn't need to be renamed as it is always used in the same way.

Same can be said for the connect URL. It will be the same throughout your program, but the value is also very likely to change in the future. So calling it CONNECT_ADVENTUREWORKS would be wrong. The name of the database may not change, but it is still not best practice since the name is a reflection of its value, which again, would be okay if the value doesn't change. Otherwise the name should be more towards how it will be used in your program. In this case it is your connection URL to the database (whatever it may be), and should be called thusly.

It's always a constant, just a less constant constant. :)

Answer 2

The idea of defining constants is that you give a value a certain semantic meaning other than the value itself (the color of headers, a circumference-square ratio, etc.) Thus, in case the value is later changed, you only have to change it in one place, and the whole application or library reflects this change.

With this in mind, it's counterproductive to bind the constant name to its value instead of its meaning for the same reason you shouldn't tell how a function does something instead of what it does: if you change the contents enough, you need to rename the constant. Furthermore, if I see COLOR_DEEP_RED in the source code, it tells little about what it is, but COLOR_PRIMARY tells me that it's the primary color of the style palette.

I don't know if it's actually considered an antipattern itself, but I clearly see reasons not to name constants by their value, but by their meaning.

Answer 3

Name your string constants for their content.

const WELCOME_MESSAGE="Welcome!";
const WELCOME_BACK_MESSAGE="Welcome back!";

That will come in handy when you're looking at a localized string.

const WELCOME_MESSAGE="Wilkommen!';
const WELCOME_MESSAGE="¡Bienvenida!';

Name your colors for their content, as well:

const COLOR_DEEP_RED=[32,0,0];
const COLOR_DEEP_BLUE=[0,0,32];

Then, reference those constants in other constants named for their use:

const TITLE_BAR_BACKGROUND_COLOR=COLOR_DEEP_RED;
const WINDOW_BORDER_COLOR=COLOR_DEEP_BLUE;

This way, all your color definitions and usages are defined in one place and can be manipulated without having to traipse all over your codebase.

That's what's worked well for me. YMMV.

Answer 4

I work mostly in SQL server which doesn't have constants at all ( you can define a function which always returns the same value ).

I would say that your naming granularity is likely too fine here. I would expect there to only be one place in your application where you welcome a user back, and therefore a named constant is not needed at all. Instead I would expect a named procedure, something like DisplayWelcomeBackDialog or similar.

Constants ( and other things such as functions, procedures, variables ) should usually be named for their meaning. In some cases a mathematical constant may be so well known that it an abbreviation can be used, say Pi = 3.1459.