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-6353a1cd21a1



D lang reference:
https://dlang.org/dstyle.html#naming_constants

On Wednesday, 9 May 2018 at 09:38:14 UTC, BoQsc 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-6353a1cd21a1
>
>
>
> D lang reference:
> https://dlang.org/dstyle.html#naming_constants

Just because.

On Wednesday, 9 May 2018 at 09:51:37 UTC, bauss wrote:
> Just because.

To add on to this.

D is not Java, it's not C++, it's not C# etc.

D is D and D has its own conventions.

You're free to write your constants in all uppercase if you want.

I guess if I should come up with an actual reason then it would be that constants are so common in D as not just constant values, but as "variables" to compile-time functions that are evaluated.

Which is different from eg. Java where you only have constant values.

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

On Wednesday, 9 May 2018 at 09:38:14 UTC, BoQsc 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?

It is D style for standard library. It is mostly arbitrary but in general sensible.
That’s it.

On Wednesday, May 09, 2018 14:12:41 Dmitry Olshansky via Digitalmars-d-learn wrote:
> On Wednesday, 9 May 2018 at 09:38:14 UTC, BoQsc 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?
>
> It is D style for standard library. It is mostly arbitrary but in
> general sensible.
> That’s it.

To an extent that's true, but anyone providing a library for use by others in the D community should seriously consider following it with regards to public symbols so that they're consistent with how stuff is named across the ecosystem. It's not the end of the world to use a library that did something like use PascalCase instead of camelCase for its function names, or which used lowercase and underscores for its type names, or did any number of other things which are perfectly legitimate but don't follow the D style. However, they tend to throw people off when they don't follow the naming style of the rest of the ecosystem and generally cause friction when using 3rd party libraries.

Stuff like how code is formatted or how internal symbols are named are completely irrelevant to that, but there's a reason that the D style guide provides naming conventions separately from saying anything about how Phobos code should look. The D ecosystem at large is better off if libraries in general follow the same naming conventions for their public symbols. Obviously, not everyone is going to choose to follow the official naming conventions, but IMHO, their use should be actively encouraged with regards to public symbols in libraries that are made publicly available.

- Jonathan M Davis

On Wednesday, 9 May 2018 at 15:20:12 UTC, Jonathan M Davis wrote:
> On Wednesday, May 09, 2018 14:12:41 Dmitry Olshansky via Digitalmars-d-learn wrote:
>> [...]
>
> To an extent that's true, but anyone providing a library for use by others in the D community should seriously consider following it with regards to public symbols so that they're consistent with how stuff is named across the ecosystem. It's not the end of the world to use a library that did something like use PascalCase instead of camelCase for its function names, or which used lowercase and underscores for its type names, or did any number of other things which are perfectly legitimate but don't follow the D style. However, they tend to throw people off when they don't follow the naming style of the rest of the ecosystem and generally cause friction when using 3rd party libraries.
>
> [...]

If this issue https://github.com/dlang-community/dfmt/issues/227 is fixed we could potentially summarize that in .editorconfig file so that anyone who wishes can easily adopt it.

On Wednesday, 9 May 2018 at 09:38:14 UTC, BoQsc 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-6353a1cd21a1
>
>
>
> D lang reference:
> https://dlang.org/dstyle.html#naming_constants

It is really helpful to write generic code. E.g. you use `myRange.empty` and you do not care what `empty` actually is. The range could be infinite and define `enum empty = false;` If you use an uppercase identifier like `EMPTY`, generic code breaks; if you don't but do otherwise, where is the boundary? The only solution is, you don't spell it different if something is a compile-time constant or not.
It is even possible that some name can refer to a type, which is usually spelled with the first letter uppercase, or a value.
On [1] it reads: `hook` is a member variable [of type `Hook`] if it has state, or an alias for `Hook` [the type itself] otherwise.
So, generally, anything is spelled camelCase except declared types as classes, interfaces, structs, unions, and aliases for things definitely known to be types.

[1] https://dlang.org/phobos/std_experimental_checkedint.html#.Checked.hook

On Wednesday, 9 May 2018 at 11:52:11 UTC, Jonathan M Davis wrote:
> On Wednesday, May 09, 2018 09:38:14 BoQsc via Digitalmars-d-learn wrote:
>> [...]
>
> Every language makes its own choices with regards to how it goes about things, some of which are purely subjective.
[...]
> - Jonathan M Davis

Just a thank you, for your patient and well written explanations!

On Tuesday, May 15, 2018 08:48:45 Martin Tschierschke via Digitalmars-d- learn wrote:
> On Wednesday, 9 May 2018 at 11:52:11 UTC, Jonathan M Davis wrote:
> > On Wednesday, May 09, 2018 09:38:14 BoQsc via
> >
> > Digitalmars-d-learn wrote:
> >> [...]
> >
> > Every language makes its own choices with regards to how it goes about things, some of which are purely subjective.
>
> [...]
>
> > - Jonathan M Davis
>
> Just a thank you, for your patient and well written explanations!

I'm glad that they've been of use.

- Jonathan M Davis