47

I know, that for C++ and Java it is a well established naming convention, that constants should be written all uppercase, with underscores to separate words. Like this (Java-example):

public final static Color BACKGROUND_COLOR = Color.WHITE;
public final static Color TEXT_COLOR = Color.BLACK;

This naming convention is easy to understand and to follow, but I ask myself, why choose this naming convention over the normal naming-convention for variables:

public final static Color backgroundColor = COLOR.WHITE;
public final static Color textColor = COLOR.BLACK;

Theres seems to be no need to change the look of constants. If we want to assign a value to them, the compiler will prevent this anyways. Actually it makes problems, if later the constant will be changed into a proper variable (because the colors get configurable for instance).

So what's the ultimate reason to write named constants all uppercase? Historical reasons?

2
  • 36
    It actually isn't a good idea to name constants in all uppercase in C++. ALL_UPPER_CASE is a convention for preprocessor macros. Thus your constants may clash with and get clobbered by preprocessor symbols.
    – Brian Neal
    Commented May 8, 2009 at 13:21
  • 1
    This might be best served as community wiki
    – lothar
    Commented May 8, 2009 at 16:47

15 Answers 15

39

I think it is not a technical problem but rather a psychological one. Naming conventions are not for the compiler to process (the computer does not really mind names) but rather for the programmer that is browsing the code to have as much information as possible with as little effort as required.

Using a different naming convention is clearly telling the reader that what you are reading is something that is FIXED at compile time and you don't need to follow through code to determine where and how the value got there.

5
  • 1
    "have as much information as possible with as little effort as required": I agree to that. In combination with 'plain text' as a programming medium, this may lead to an uppercase convention. If only the editor would show constants in a different color, no special casing was needed. Nowadays, most programming tools show more information, so I guess naming conventions are slowly going to fade.
    – xtofl
    Commented May 8, 2009 at 10:47
  • 8
    Does it really have to be fixed at compile-time though? What about a runtime constant, e.g. the time the program started executing? What about fixed collections, which can't be understood by the compiler but are still effectively constant.
    – Jon Skeet
    Commented May 8, 2009 at 10:49
  • 2
    @Jon Skeet: That's a good point: how to deal with frontiers. What is the definition of a constant? Here you are fighting with the language you use. To me they should be upper case since they are constants... regardless of the limitations the language/compiler they are constants. Commented May 8, 2009 at 11:49
  • 3
    Having enums scoped by their type is a clearer indication of the constness than all-uppercase, as it not only shows that it's a constant but also what sort of constant. All-uppercase was for symbols that are external to the language, but Java and C# don't have precompilers. Besides, all-upper is hard to read and ugly. Commented Sep 23, 2010 at 22:57
  • This only provides an answer to the question “why have a different convention for constants?”. Not an answer to the question “why this specific convention?”. Surely the latter is likely to have an answer since we are talking about two specific programming languages (i.e. we don’t need generalized answers). Commented Apr 22, 2022 at 14:41
21

I believe in C++ it's a convention carried over from the days of using the preprocessor to #define constant values. Back then, it was done to avoid having the preprocessor trample all over your source code, as the usual conventions for C function and variable names would make them mixed case or lower case.

From a C++ point of view, I would say that it's a bad idea to make your constants all-uppercase. I've had to debug more than one build problem because of this - remember that the C++ preprocessor does know nothing about namespaces and naming scope and will happily substitute what it thinks is appropriate even though it is rather inappropriate.

2
  • 10
    This is exactly what I was going to say. Today, in C++, it is an anti-idiom to use ALL_UPPER_CASE for constants because the preprocesor may clobber your constants with some macro it picked up from somewhere you didn't expect (like your vendor's C OS header files).
    – Brian Neal
    Commented May 8, 2009 at 13:18
  • 4
    This must be why Google uses kConstantName in their naming conventions. An alternative that somewhat preserves the old style would be k_CONSTANT_NAME. Commented Jan 25, 2010 at 2:40
17

I can imagine that initially, back in the C days, people would implement "constants" symbolically, using the pre-processor:

typedef unsigned int Color;
#define BACKGROUND_COLOR 0xffffff

Such "constants" are just prettified literals, and as such they don't behave quite as variables. You can't, for example, take the adress of such a "constant":

Color *p = &BACKGROUND_COLOR; // Breaks!

For this reason, it makes sense to have them "stand out", as they're really not just "variables you can't change".

4
  • 3
    But isn't that the IDE's job, nowadays? Making them stand out?
    – xtofl
    Commented May 8, 2009 at 10:48
  • 2
    Not everyone uses an IDE all the time, even today. I still spend a noticable fraction of my time (~10%) in vi.
    – dagorym
    Commented May 8, 2009 at 15:09
  • 7
    Don't forget the #define macros which can lead to nasty side effects. Having them all uppercase gives a visual cue for 'here be dragons!'
    – Skizz
    Commented Feb 19, 2010 at 11:32
  • I really suggest a google image search for "syntax on" (motorcycle image)
    – yeoman
    Commented Oct 24, 2018 at 12:46
17

If I know something is a constant, I can refer to it multiple times and know it won't change. In other words, I know that:

Color black = Colors.BLACK;
foo(black);
foo(black);

is the same as:

foo(Colors.BLACK);
foo(Colors.BLACK);

That can be useful to know sometimes. Personally I prefer the .NET naming convention, which is to use Pascal case for constants (and methods):

Foo(Colors.Black);
Foo(Colors.Black);

I'm not a big fan of shouty case... but I do like constants being obviously constants.

5
  • 4
    The question is about: why use a different naming scheme to denote constancy? Not about why constancy is useful.
    – xtofl
    Commented May 8, 2009 at 10:43
  • 8
    My answer doesn't talk about why constancy is useful - it talks about why knowing about constancy is useful. That's where naming comes in.
    – Jon Skeet
    Commented May 8, 2009 at 10:48
  • 4
    I ALSO PREFER MY CODE NOT TO SHOUT AT ME AND THUS TEND TO USE PascalCase - IT'S SO MUCH MORE READABLE!!!!!!!11
    – yeoman
    Commented Oct 24, 2018 at 12:44
  • I assume @JonSkeet that any downvote is because you posted an answer that doesn't answer the question that was asked: "Why should named constants be all uppercase in C++/Java?" You don't state WHY they should be all uppercase. And even shows enum types as a replacement but not an answer for the question. Commented Sep 12, 2019 at 19:17
  • 1
    @RodneyS.Foley: I'm not sure why you think I'm referring to enums - I don't mention enums at all. But I think I do answer the question, by stating why it's useful to be able to tell the difference between constants and non-constants.
    – Jon Skeet
    Commented Sep 12, 2019 at 19:24
16

Do not use ALL_CAPS for constants just because constants used to be macros.

This quote from C++ Core Guidelines sums it all.

8

In C (and then C++), symbols that were defined with the preprocessor #define directive were written all in caps as a loud signal to developers that the code was not as it seemed and to not treat as a normal symbol. Constants did not initially exist in K&R C (although const was brought back from C++ later) so developers used #define instead, hence the caps.

For some reason, this got twisted into Java as "constants are caps", hence the current misguided (IMO) convention.

6

I think uppercase constants are a bad heritage from C. The logic behind is the same as when using underscores as prefixes for private members. This is technical stuff which is already expressed by Java keywords like private or, in the case of constants, static final.

0
5

Actually most C++ naming guidelines (including ISO, Boost, Sutter & Stroustrup and Google) strongly discourages naming constants with all caps. This is because macros also use all caps and they can be littered all over in header files potentially creating strange behaviors. People still use all caps anyway because they learn from old C/K&R or old legacy code. However in Modern C++ new code you should avoid using all caps for anything except macros.

My pet theory for why all caps exists at all is that on very old machines, code was being entered directly in machine code using numeric keypads. When assembly language arrived on the scene, it only used all caps because keyboard at that time weren't standardized and some keyboards were limited ,for example, using same numeric keypads to enter alphabets like in feature phones. This got then carried over to many early languages like BASIC which is all caps everything. When actual terminals became available and keyboards started to get standardized, people started using mixed cases without reservations and all caps got reserved for something that is rare in occurrence like constants compared to functions and variables.

Most C++ guidelines now agree on using "k" as prefix for constant followed by name with either underscore or CamelCase. I personally prefer kCameCase because it easily allows to distinguish from variables which are named with under_scores.

const float kFixedRadius = 3.141;
3

Basically, back when people were in love with C, and C++ & Java were either new or not yet created, people used all caps for preprocessor constant names, to indicate that they weren't actually variables.

#define INT_CONST 4
#define STRING_CONST "Yello."
#define FLOAT_CONST 3.6122448

Considering that this was the only real way to define a true constant in C (it's still possible to change const variables if you know how), preprocessor constants like that were just seen as constants, and as such the meaning of all-caps names shifted from preprocessor constants to simply constants in general. This then carried over into later languages, becoming the standard "consts = capitals" practice.

Other languages have their own preferred style, however (for example, C# & .NET prefer PascalCase), so it's generally best to use the preferred style if there is one.

2

With uppercase constants long formulas are much easier to read, you don't have to guess which element can vary and which can not. It's of course only a convention, but helpful one.

1
  • 1
    That can be achieved with many methods of indicating a constant, so isn't unique to using uppercase names. Other methods don't have the same shoutiness too. Commented Feb 6, 2019 at 20:09
2

It's a workaround for your development tools not being able to spot the properties of an identifier in a convenient way.

Much like Hungarian notation.

When your IDE gets better, you won't need any naming convention but the one that dictates that a name is comprehensive information on what an identifier means.

Even that may evolve: why not create a programming system where you just create identifiers, and add properties to it like "brief description", "type", ... When the tool arrives that can do this in a convenient way, I'm in. "Intentional Programming" is a hint.

1
  • Languages with "const" or "final" are already there.
    – nclark
    Commented Aug 4, 2023 at 16:49
1

Probably you are right. Computers and compilers (especially) were not so fast as today.

Joel Spolsky mentioned in one of his essays how impressed he was with compilation time of new version of Turbo Pascal.

I remember when compilation of not too big program (10-20KLOC) with overlays in Turbo Pascal 5.0 on PC XT 10MHz took about 20 minutes...

I suppose that waiting for compilation to detect error was not acceptable.

And convention like that helps to avoid errors and wasted time during broken compilation.

0

When programming, it is important to create code that is understandable by humans. Having naming conventions helps to do this. This is best when looking at code that you didn't write and makes the code more maintainable because it is easy to distinguish from constants and variables.

0

Coding conversions are to improve readability. You don't have to use letters. Java allows $ symbol for example.

public final static Color $$ = COLOR.WHITE;
public final static Color $_ = COLOR.BLACK;

You could number your variables too, but that doesn't mean its a good idea. ;)

0

This is purely to help the programmer understand what he or she is looking at from a glance. It helps to know that a constant is being used so that the value won't change no matter how you refer to it.

There isn't really a reason regarding the compiler side of things. Naming conventions are purely that, conventions, not really technical restrictions.

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