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.

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

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.

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...