Why The D Style constants are written in camelCase?

[Jonathan M Davis]

On Wednesday, May 09, 2018 09:38:14 BoQsc via Digitalmars-d-learn wrote:
> The D Style suggest to camelCase constants, while Java naming
> conventions always promoted uppercase letter.
>
> Is there an explanation why D Style chose to use camelCase
> instead of all UPPERCASE for constants, was there any technical
> problem that would appear while writing in all UPPERCASE?
>
>
>
> Java language references:
> https://en.wikipedia.org/wiki/Naming_convention_(programming)#Java
> https://www.javatpoint.com/java-naming-conventions
> http://www.oracle.com/technetwork/java/codeconventions-135099.html
> https://medium.com/modernnerd-code/java-for-humans-naming-conventions-6353
> a1cd21a1
>
>
>
> D lang reference:
> https://dlang.org/dstyle.html#naming_constants

Every language makes its own choices with regards to how it goes about
things, some of which are purely subjective.

As I understand it, the idea of having constants being all uppercase comes
from C, where it was done to avoid problems with the preprocessor.
Typically, in C, macro names are in all uppercase so that symbols which
aren't intended to involve macros don't end up with code being replaced by
macros accidentally. Because constants in C are typically macros, the style
of using all uppercase for constants has then gotten into some languages
which are descendants of C, even if they don't have macros and don't have
the same technical reasons as to why all uppercase would be desired (Java
would be one such language). Ultimately, the fact that Java uses all
uppercase letters for constants is a convention and not good or bad from a
technical perspective.

Ultimately, the reason that D does not follow that convention is that Andrei
Alexandrescu didn't like it, and it's arguably a highly subjective choice,
but there are reasons why it can matter.

"Constants" are used so frequently in D and with so many different
constructs (templates, enums, static const, etc.) that having them be all
uppercase would have a tendancy to result in a _lot_ of symbols which were
all uppercase. Code is often written in such a way that you don't have to
care whether a symbol is an enum, a function, or a const/immutable static
variable. e.g. in this code

enum a = foo;

foo has to be known at compile-time. However, foo could be a number of
different kinds of symbols, and I don't necessarily care which it is. Right
now, it could be another enum, but maybe tomorrow, it makes more sense for
me to refactor my code so that it's a function. If I named enums in all
caps, then I would have had

enum A = FOO;

and then when I changed FOO to a function, I would have had to have changed
it to

enum A = foo;

By having the coding style make everything that could be used as a value be
camelCase, you don't have to worry about changing the casing of symbol names
just because the symbol was changed. You then only have to change the use of
the symbol if the change to the symbol actually makes it act differently
enough to require that the code be changed. If the code continues to work
as-is, you don't have to change anything. Obviously, different kinds of
symbols aren't always interchangeable, but the fact that they frequently are
can be quite valuable and can reduce code maintenance, whereas having those
kinds of symbols be named with different casing would just increase code
maintenance.

So, for D, using camelCase is advantageous from a code maintenance
perspective, and I'd argue that the result is that using all uppercase for
constants is just making your life harder for no real benefit. That's not
true for Java, because Java has a lot fewer constructs, and they're rarely
interchangeable. So, using all uppercase doesn't really cause any problems
in Java, but D is not Java, so its situation is different.

All that being said, you're obviously free to do whatever you want in your
own code. I'd just ask that any public APIs that you make available in
places like code.dlang.org follow the D naming conventions, because that
will cause fewer problems for other people using your code.

- Jonathan M Davis