3

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?

closed as too broad by gnat, jwenting, Laiv, Andy, Blrfl Mar 18 at 10:27

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 6
    Way too broad. Depends on context. In a list of colours, calling a constant DEEP_RED makes perfect sense e.g., in a list of colour values used in a user interface, you'd name them for the things being coloured, like SCROLLBAR_BACKGROUND_COLOUR = Colours.DEEP_RED; – jwenting Mar 18 at 7:30
  • That is an anti-pattern. Two problems, first: Rate of change. The name of the constant within the code will change less frequently then the contents of it. That is the whole point of abstracting it, to allow simple and global change. Second: level of abstraction. As a benefit of putting the constant behind a name, the name can mean something. Maybe Title_On_Error vs Title_On_Success. Try and make the name say something important about how/when it is used. – Kain0_0 Mar 18 at 7:31
  • Hmm... why would team members who don't need to know about the title bar ever see that string constant in their code? If you use TITLEBAR_MESSAGE for strings that are not actually title bar messages, then it's not wonder that the practice feels wrong to you. – Christian Hackl Mar 18 at 7:45
  • Both are readable. Which one do you think is more meaningful for the reader in each case? I would dare to say that it depends on the place and the moment you use one or another. Anyways, you could use both altogether as it was already suggested. – Laiv Mar 18 at 7:46
  • Possible duplicate of Usage of magic strings/numbers – Blrfl Mar 18 at 10:27
6

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. :)

1

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.

0

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.

0

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.