Return to Answer

Some answers seem like they want to contradict each other, like the one by Eric, and the one by Jarrod. But they are in perfect agreement.

A constant must add meaning.

Defining COMMA to be a comma doesn't add meaning, because we know that a comma is a comma. Instead we destroy meaning, because now COMMA might actually not be a comma anymore.

If you use a comma for <purpose> you can declare <PURPOSE> to be a comma.

So while city + CharacterClass.COMMA + state is horribly wrong, city + CITY_STATE_DELIMITER + state is acceptable. How acceptable it is depends on many factors that are currently unknown.

Use functions for formatting

I'd personally prefer Format<PurposeOfFormat>(city, state) and wouldn't care about how the body of that function looks as long as it's short and passes the test cases. In other words, if you have to worry about using constants to implement formatting rules, you may consider to use functions for the formatting rules instead - that way the question about using constants inside these functions becomes so irrelevant that nobody has to care.

A constant must add meaning.

Defining COMMA to be a comma doesn't add meaning, because we know that a comma is a comma. Instead we destroy meaning, because now COMMA might actually not be a comma anymore.

If you use a comma for a purpose and want to use a named constant, name it after it's purpose. Example:

• city + CharacterClass.COMMA + state = bad
• city + CITY_STATE_DELIMITER + state = good

Use functions for formatting

I personally prefer FormatCityState(city, state) and don't care about how the body of that function looks as long as it's short and passes the test cases.

Some answers seem like they want to contradict each other, like the one by Eric, and the one by Jarrod. But they are in perfect agreement.

A constant must add meaning.

Defining COMMA to be a comma doesn't add meaning, because we know that a comma is a comma. Instead we destroy meaning, because now COMMA might actually not be a comma anymore.

If you use a comma for <purpose> you can declare <PURPOSE> to be a comma.

So while city + CharacterClass.COMMA + state is horribly wrong, city + CITY_STATE_DELIMITER + state is acceptable. How acceptable it is depends on many factors that are currently unknown.

I'd personally prefer Format<PurposeOfFormat>(city, state) and wouldn't care about how the body of that function looks as long as it's short and passes the test cases. In other words, if you have to worry about using constants to implement formatting rules, you may consider to use functions for the formatting rules instead - that way the discussion if you want to use constants internally becomes so irrelevant that nobody has to care.

Some answers seem like they want to contradict each other, like the one by Eric, and the one by Jarrod. But they are in perfect agreement.

A constant must add meaning.

Defining COMMA to be a comma doesn't add meaning, because we know that a comma is a comma. Instead we destroy meaning, because now COMMA might actually not be a comma anymore.

If you use a comma for <purpose> you can declare <PURPOSE> to be a comma.

So while city + CharacterClass.COMMA + state is horribly wrong, city + CITY_STATE_DELIMITER + state is acceptable. How acceptable it is depends on many factors that are currently unknown.

Use functions for formatting

I'd personally prefer Format<PurposeOfFormat>(city, state) and wouldn't care about how the body of that function looks as long as it's short and passes the test cases. In other words, if you have to worry about using constants to implement formatting rules, you may consider to use functions for the formatting rules instead - that way the question about using constants inside these functions becomes so irrelevant that nobody has to care.

Some answers seem like they want to contradict each other, like the one by Eric, and the one by Jarrod. But they are in perfect agreement.

A constant must add meaning.

Defining COMMA to be a comma doesn't add meaning, because we know that a comma is a comma. Instead we destroy meaning, because now COMMA might actually not be a comma anymore.

If you use a comma for <purpose> you can declare <PURPOSE> to be a comma.

So while city + CharacterClass.COMMA + state is horribly wrong, city + CITY_STATE_DELIMITER + state is acceptable. How acceptable it is depends on many factors that are currently unknown. I'd personally prefer Format<PurposeOfFormat>(city, state) and wouldn't care about how the inside looks as long as it's short and passes the test cases.

Some answers seem like they want to contradict each other, like the one by Eric, and the one by Jarrod. But they are in perfect agreement.

A constant must add meaning.

Defining COMMA to be a comma doesn't add meaning, because we know that a comma is a comma. Instead we destroy meaning, because now COMMA might actually not be a comma anymore.

If you use a comma for <purpose> you can declare <PURPOSE> to be a comma.

So while city + CharacterClass.COMMA + state is horribly wrong, city + CITY_STATE_DELIMITER + state is acceptable. How acceptable it is depends on many factors that are currently unknown. 

I'd personally prefer Format<PurposeOfFormat>(city, state) and wouldn't care about how the body of that function looks as long as it's short and passes the test cases. In other words, if you have to worry about using constants to implement formatting rules, you may consider to use functions for the formatting rules instead - that way the discussion if you want to use constants internally becomes so irrelevant that nobody has to care.