www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why The D Style constants are written in camelCase?

reply BoQsc <vaidas.boqsc gmail.com> writes:
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
May 09 2018
next sibling parent reply bauss <jj_1337 live.dk> writes:
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.
May 09 2018
parent bauss <jj_1337 live.dk> writes:
On Wednesday, 9 May 2018 at 09:51:37 UTC, bauss wrote:

 Just because.


To add on to this.



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.
May 09 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
May 09 2018
parent reply Martin Tschierschke <mt smartdolphin.de> writes:
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!
May 15 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
May 15 2018
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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.
May 09 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
May 09 2018
parent Arun Chandrasekaran <aruncxy gmail.com> writes:
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.
May 09 2018
prev sibling parent Q. Schroll <qs.il.paperinik gmail.com> writes:
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
May 13 2018