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
