Hi

I watched Dconf'23 livestreams. There were some talks about how to write safe, readable and good quality code.

Would you consider creating a 'D Core Guidelines' online document with good, bad examples?

I found the C++ core guidelines very useful.

Example: Passing params to function
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f16-for-in-parameters-pass-cheaply-copied-types-by-value-and-others-by-reference-to-const

Slawek

On Thursday, 31 August 2023 at 19:00:36 UTC, slawtul wrote:

There are already bits and pieces of that in the spec, namely the "best practices" notes there. Also the D style guidelines, although it is - obviously - mostly about style as opposed to technical choices.

On Thursday, 31 August 2023 at 22:51:51 UTC, Dukc wrote:

Hi, thanks
Yes, core guidelines are rather about technical choices of experienced programmers for 'D' noobs.

On Thursday, 31 August 2023 at 19:00:36 UTC, slawtul wrote:

Would interest me too, it seems that technical guidelines have changed over time so it's not easy to know what is considered to be the "D-Style" of doing things now.

Though I can imagine that it would be hard to find a guideline where most people would agree for.

Personally, I think the code in the standard library should reflect how we write technical solutions to problems.

However, standard library is aging under the evolution of the language and can't adapt to new features without breaking.

So if there is a technical guideline for this decade let me know.

On Friday, 1 September 2023 at 11:51:53 UTC, sighoya wrote:

Having watched most of DConf talks: the guidelines are in constant evolution.

If you mix up recommendation from Atila Neves, Robert Schadek and the students that made a networked paint program, I feel like you will end up with something that resemble the current recommended D style.

Some of them disagreed completely, but you can find recurring themes.

On Friday, 1 September 2023 at 11:51:53 UTC, sighoya wrote:

I'm not a fan of that. Just to pull out a random function from the standard library:

void remove(scope const(char)[] name) @trusted nothrow @nogc

That's absolutely hideous. Fine if someone else wants write that stuff, but I'd rather use Java to reduce the verbosity.

Idiomatic D code is code that passes the tests. Some folks think there's no such thing as too many attributes. I think one attribute is too many. Some think everything but main should be private. I seldom use private. D is useful in many domains, and for solo programmers as well as large teams, so it's futile to come up with general guidelines.

On Friday, 1 September 2023 at 15:46:49 UTC, bachmeier wrote:

Hi, thanks for all replies.

C++ is also used in many domains but Mr. Herb Sutter and Mr. Bjarne Stroustrup came to the conclusion that 'Cpp++ core guidelines' has a purpose.

Please take a look at introduction: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-introduction

On Saturday, 2 September 2023 at 09:19:04 UTC, slawtul wrote:

I have read (a former incarnation) of the C++ "core" guidelines and a subset of the Boost libraries. Those readings provided motivation to move on from my C++/CUDA life. The sheer size and complexity of even expertly crafted documentation/code sends an unambiguous message.

D, as you will have noted from the responses so far, appeals to programmers with widely differing interests and experience. Additionally I, and I imagine many others, adopt a different style when writing performance critical library components than I do when knocking out a command line utility. You may have better luck getting what you're looking for if you provide some anticipated use scenarios.

That said, I don't know of any D document similar to the C++ "core" guidelines but I found this to be helpful early on after working through some tutorial material: https://p0nce.github.io/d-idioms/

Perhaps as an intermediate goal/product you can contribute a document that would have met your needs more directly (hopefully somewhat slimmer than the C++ variant! :-). The D community is small but, I've found, quite appreciative of good work.

On Saturday, 2 September 2023 at 16:08:43 UTC, Bruce Carneal wrote:

Yeah, this is what I was getting at in my comment. I use D more than anything as a scripting language (I no longer write Ruby). In those cases, I don't worry about performance at all, the code will be fast no matter how I write it, and the garbage collector is the best thing ever. Sometimes I use it for reading in large datasets, and I might disable/avoid the garbage collector if it has a practical impact. Then there is the Mir case, where the goal is performance at all costs, so that's written in betterC. Others want extremely safe code, so they put attributes everywhere. In the absence of a use case, you just can't tell people how to write their code.

C++, on the other hand, is focused mainly on cases where you want performance. Folks adopting that mindset with D will give silly responses to questions. One example that comes to mind from years ago was a piece of advice about string concatentation. The person giving the advice implicitly assumed the user wanted to prevent allocation above all else. That just isn't a consideration for much (most?) of the D code that's written using strings.