www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Core Guidelines?

reply slawtul <slawek.tuleja gmail.com> writes:
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
Aug 31 2023
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 31 August 2023 at 19:00:36 UTC, slawtul wrote:

 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?


There are already bits and pieces of that in the spec, namely the 
"best practices" notes there. Also the [D style 
guidelines](https://dlang.org/dstyle.html), although it is - 
obviously - mostly about style as opposed to technical choices.
Aug 31 2023
parent slawtul <slawek.tuleja gmail.com> writes:
On Thursday, 31 August 2023 at 22:51:51 UTC, Dukc wrote:

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

 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?


 There are already bits and pieces of that in the spec, namely 
 the "best practices" notes there. Also the [D style 
 guidelines](https://dlang.org/dstyle.html), although it is - 
 obviously - mostly about style as opposed to technical choices.


Hi, thanks
Yes, core guidelines are rather about technical choices of 
experienced programmers for 'D' noobs.
Sep 01 2023
prev sibling parent reply sighoya <sighoya gmail.com> writes:
On Thursday, 31 August 2023 at 19:00:36 UTC, slawtul wrote:

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


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.
Sep 01 2023
next sibling parent Guillaume Piolat <first.name gmail.com> writes:
On Friday, 1 September 2023 at 11:51:53 UTC, sighoya wrote:

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

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


 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.


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.
Sep 01 2023
prev sibling parent reply bachmeier <no spam.net> writes:
On Friday, 1 September 2023 at 11:51:53 UTC, sighoya wrote:


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


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.
Sep 01 2023
parent reply slawtul <slawek.tuleja gmail.com> writes:
On Friday, 1 September 2023 at 15:46:49 UTC, bachmeier wrote:

 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.


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


 ...The aim is to help C++ programmers to write simpler, more 
 efficient, more maintainable code...
Sep 02 2023
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Saturday, 2 September 2023 at 09:19:04 UTC, slawtul wrote:

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

 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.


 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


 ...The aim is to help C++ programmers to write simpler, more 
 efficient, more maintainable code...




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.
Sep 02 2023
parent reply bachmeier <no spam.net> writes:
On Saturday, 2 September 2023 at 16:08:43 UTC, Bruce Carneal 
wrote:


 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.


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.
Sep 02 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/2/2023 9:45 AM, bachmeier wrote:

 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.
 


String concatenation tends to be highly useful in CTFE code, and runtime 
performance considerations don't exist.
Sep 02 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 3 September 2023 at 05:52:12 UTC, Walter Bright wrote:

 String concatenation tends to be highly useful in CTFE code, 
 and runtime performance considerations don't exist.


Well, it depends there too since CTFE string concat has 
absolutely terrible performance if you do a lot of it.

A small x ~ y in CTFE is virtually invisible, I'd be fine with 
that. But a loop of string ~= thing in ctfe quickly becomes a 
compile time killer - it is at least quadratic time.

Redoing that as a single pre-allocated char[] that is slice 
assigned can take very noticeable times off builds. For example, 
my jsvar.d used to have one that ballooned builds to about 6 
seconds. I rewrote it with a length calculation loop, single 
allocation, slice assign loop instead of a ~= loop, and it 
brought it back down to 2 seconds. (Still a bit slow, but 
obviously 2 is much faster than 6.)

Or my jni.d when running over android, it used to use a CTFE 
string.replace and it took *minutes* to compile along with dozens 
of gigabytes of ram.  Prerunning that, so it was just two 
separate string literals (yes, this ctfe use only ended up in two 
permutations when all was said and done) brought that back to the 
land of reality too.

So CTFE concat I almost think is *more* dangerous than runtime 
concat. At least the runtime concat has *consistently* decent 
performance.

That said tho, anybody reading this, if your strings are short, 
CTFE concat works perfectly well. Don't overcomplicate code 
unless the strings are long and there's an append loop, then you 
MIGHT notice the difference.
Sep 03 2023