www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Style document

reply Dejan Lekic <dejan.lekic gmail.com> writes:
As many of you probably know, there is a D Style document 
describing proposed style for our D source code.

The document (web page) can be found here: 
https://dlang.org/dstyle.html

My question is regarding the enum values, and (manifest) 
constants. Throughout the druntime for an example, enum values 
and manifest constants are SNAKE_CASE style, while the 
abovementioned document recommends the camelCase for both: 
[Naming 
constants](https://dlang.org/dstyle.html#naming_constants) , 
[Enum members](https://dlang.org/dstyle.html#naming_enum_members)

So, considering that something as critical to us as the druntime 
uses a different style, should we perhaps modify the D Style page 
and change recommended style for constants and enum members to 
SNAKE_STYLE (which I also prefer)?
Mar 08
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 8 March 2025 at 10:15:47 UTC, Dejan Lekic wrote:

 Throughout the druntime for an example, enum values and 
 manifest constants are SNAKE_CASE style, while the 
 abovementioned document recommends the camelCase for both: 
 [Naming 
 constants](https://dlang.org/dstyle.html#naming_constants) , 
 [Enum 
 members](https://dlang.org/dstyle.html#naming_enum_members)

 So, considering that something as critical to us as the 
 druntime uses a different style, should we perhaps modify the D 
 Style page and change recommended style for constants and enum 
 members to SNAKE_STYLE (which I also prefer)?


D has been around for more than 20 years, and core D projects 
like DMD, druntime, and Phobos contain a lot of old code that 
does not hold up to modern standards. So the fact that SNAKE_CASE 
constants are used in some parts of druntime is not a strong 
argument for using them elsewhere.

Also, druntime in particular uses a lot of `extern(C)` bindings, 
and SNAKE_CASE is the standard way of naming constants in C.

Of course, you don't have to follow the D style guide for your 
own projects if you don't want to. For example, I use tabs for 
indentation in my personal projects, rather than spaces like the 
style guide suggests.
Mar 08
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Saturday, 8 March 2025 at 11:30:44 UTC, Paul Backus wrote:

 D has been around for more than 20 years, and core D projects 
 like DMD, druntime, and Phobos contain a lot of old code that 
 does not hold up to modern standards. So the fact that 
 SNAKE_CASE constants are used in some parts of druntime is not 
 a strong argument for using them elsewhere.

 Also, druntime in particular uses a lot of `extern(C)` 
 bindings, and SNAKE_CASE is the standard way of naming 
 constants in C.

 Of course, you don't have to follow the D style guide for your 
 own projects if you don't want to. For example, I use tabs for 
 indentation in my personal projects, rather than spaces like 
 the style guide suggests.


Thanks Paul! So do you think people who are working on libraries, 
ie. code that is supposed to be used by a wider D developer 
audience, should follow the D Style document?
Mar 08
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 8 March 2025 at 15:34:03 UTC, Dejan Lekic wrote:

 Thanks Paul! So do you think people who are working on 
 libraries, ie. code that is supposed to be used by a wider D 
 developer audience, should follow the D Style document?


If you're working on a project that you want other D developers 
to *contribute* to, following the style guide will probably make 
it easier for them to do so (for example, they won't have to 
change their settings for tools like `dfmt` or `dscanner`).

For making your code easy for other developers to *use*, I don't 
think code style matters all that much. Things like quality of 
documentation and integration with the `dub` package manager are 
far more important.
Mar 08
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 09/03/2025 4:54 AM, Paul Backus wrote:

 (for example, they won't have to change their settings for tools like | 
 dfmt| or |dscanner|).


Nobody contributing to a project has to change their configuration 
unless they've done something really bad.

You commit the appropriate configuration file per project and you are done.
Mar 08
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, March 8, 2025 8:34:03 AM MST Dejan Lekic via Digitalmars-d wrote:

 Thanks Paul! So do you think people who are working on libraries,
 ie. code that is supposed to be used by a wider D developer
 audience, should follow the D Style document?


The style guide is largely broken into two parts - the rules about how to
name symbols, and the additional formatting rules for contributing to
official projects such as Phobos or druntime.

The naming rules are rules that every public library should be following if
the developers working on it want to fit into the D ecosystem, and some
programmers will complain if a library does not follow the official naming
guidelines (whereas some other progammers won't care much). Ideally,
everyone would be following the naming guidelines in the style guide, but
some people prefer not to for a variety of reasons. And of course, when
you're dealing with bindings to other languages, you can't always follow the
D naming conventions.

On the other hand, the formatting rules in the guide are almost entirely
aimed at contributions to official D source code, and there's no reason to
follow those if you don't want to (outside of contributions to official D
source code). It has no impact on users of a library, and it really only
matters to folks contributing to it. So, whatever formatting rules you
follow when writing a library should be based on what the contributors to
that library want to do.

There is a bit about general whitespace stuff at the top of the style guide
which is not specific to official D sources (e.g. using 4 spaces for
indentation and not using tabs), and prior to the Phobos style guide stuff
added later on, it was all that the style guide said about formatting. So,
maybe it should be moved to the Phobos section, but it does provide a nice
default for those who don't feel strongly about it. Ultimately though, it
doesn't matter to the users of a library, whereas the naming conventions
directly impact those users.

Of course, for projects that are not made public libraries, even the naming
rules arguably don't need to be followed, though it's arguably a good habit
to get into.

- Jonathan M Davis
Mar 08
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Saturday, 8 March 2025 at 18:46:16 UTC, Jonathan M Davis wrote:

 The naming rules are rules that every public library should be 
 following if the developers working on it want to fit into the 
 D ecosystem, and some programmers will complain if a library 
 does not follow the official naming guidelines (whereas some 
 other progammers won't care much). Ideally, everyone would be 
 following the naming guidelines in the style guide, but some 
 people prefer not to for a variety of reasons. And of course, 
 when you're dealing with bindings to other languages, you can't 
 always follow the D naming conventions.


Even if I do not deal with bindings, but just work on a library 
(public, opens-ource) I still do not prefer the camelCase enum 
member names because the most obvious choices CLASH with D 
keywords. The most obvious one, that many people would want to 
use I am sure, but they can't is `default`. Another conflicting 
one is `double` that you want to use for values that are double 
of the previous enum value, etc...
Mar 12
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, March 12, 2025 2:26:47 PM MDT Dejan Lekic via Digitalmars-d wrote:

 On Saturday, 8 March 2025 at 18:46:16 UTC, Jonathan M Davis wrote:

 The naming rules are rules that every public library should be
 following if the developers working on it want to fit into the
 D ecosystem, and some programmers will complain if a library
 does not follow the official naming guidelines (whereas some
 other progammers won't care much). Ideally, everyone would be
 following the naming guidelines in the style guide, but some
 people prefer not to for a variety of reasons. And of course,
 when you're dealing with bindings to other languages, you can't
 always follow the D naming conventions.


 Even if I do not deal with bindings, but just work on a library
 (public, opens-ource) I still do not prefer the camelCase enum
 member names because the most obvious choices CLASH with D
 keywords. The most obvious one, that many people would want to
 use I am sure, but they can't is `default`. Another conflicting
 one is `double` that you want to use for values that are double
 of the previous enum value, etc...


For keywords as symbol names, the style guide mandates that you add a
trailing underscore, so default becomes default_, and double becomes
double_.

In my experience, it doesn't come up very often, but we do have an official
way to deal with such naming conflicts. Obviously, not everyone agrees with
some of the naming rules, and no one is forcing anyone to follow them
(outside of official D source code), so some projects do not follow the
official naming guidelines. Ideally though, libraries on code.dlang.org
would be following those naming guidelines. So, I'd encourage you to follow
the D style guide with your own code that you make public, but it's up to
you.

- Jonathan M Davis
Mar 13
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Saturday, 8 March 2025 at 10:15:47 UTC, Dejan Lekic wrote:

 As many of you probably know, there is a D Style document 
 describing proposed style for our D source code.

 [...]


What if we just deleted the whole thing?
Mar 08
next sibling parent matheus <matheus gmail.com> writes:
On Saturday, 8 March 2025 at 16:33:51 UTC, monkyyy wrote:

 On Saturday, 8 March 2025 at 10:15:47 UTC, Dejan Lekic wrote:

 As many of you probably know, there is a D Style document 
 describing proposed style for our D source code.

 [...]


 What if we just deleted the whole thing?


You know what? - I really think that by this time we should 
already have had a way to have source as a basic string pattern 
and a style format, something like HTML and CSS but for source 
code.

So I could have my own style without bothering and following 
others.

Sometimes is awful to read different sources from different 
organizations with different styles.

Matheus.
Mar 08
prev sibling parent Kapendev <alexandroskapretsos gmail.com> writes:
On Saturday, 8 March 2025 at 16:33:51 UTC, monkyyy wrote:

 On Saturday, 8 March 2025 at 10:15:47 UTC, Dejan Lekic wrote:

 As many of you probably know, there is a D Style document 
 describing proposed style for our D source code.

 [...]


 What if we just deleted the whole thing?


BASED
Mar 08