Naming: Why should named constants be all uppercase in C++/Java?

Question

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?

Answer 1

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.

Answer 2

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".

Answer 3

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.

Answer 4

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.

Answer 5

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

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

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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;

Answer 10

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.

Answer 11

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.

Answer 12

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.