www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Best practices

reply "JS" <js.mdnq gmail.com> writes:
There seems to be a lot of stuff D can do but no best practices 
for optimal code(performance or safety).

Someone should write a book about it!

e.g., The scope(this) thread... is that something I should start 
doing because it is much safer or what? A book with all the 
goodies inside it would make life easier and get people off on 
the right foot instead of having to learn the hard way(it's bad 
enough with all the weird bugs in D already).
Aug 27 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 27, 2013 at 10:59:40PM +0200, JS wrote:

 There seems to be a lot of stuff D can do but no best practices for
 optimal code(performance or safety).
 
 Someone should write a book about it!


I think we're aware of that. :) The problem is, nobody has stepped up to
the plate to far.

As a general rule, though, I'd say that for the most part, Phobos code
represents the current D best practices (though I do have to qualify my
statement that *older* Phobos code may not necessarily meet this
criterion). Or, at the very least, it serves as a pretty good example of
what typical D code should look like.

Now, Phobos is still far from perfect, so others may disagree with my
suggestion that Phobos code is exemplary D code. I *will* say, however,
that reading Phobos source code has improved my own D coding style by
leaps and bounds. It's a rather enlightening experience, and highly
recommended if you want to master D.

And I keep repeating myself, but reading Phobos source code is actually
far less frightening than it sounds.  Standard libraries' source code in
many programming languages have a reputation for being obscure and
arcane, and not representative of "normal" code in that language, but
Phobos is a shining counterexample. It is surprisingly pleasant to read,
and very much how regular D code should look like (except for a few dark
corners that, hopefully, will be cleaned up eventually).



 e.g., The scope(this) thread... is that something I should start
 doing because it is much safer or what?


scope(this) isn't implemented yet, only proposed. :)

Even if it ultimately is rejected, I hope that at least it would have
helped more people know about the potential pitfalls in object
creation/destruction. Like floating point arithmetic, it's a lot more
tricky than it may appear at first glance, and maybe I'll be bold and
say that most existing code is actually incorrect in this area, it's
just that the problems don't surface that often.

(Another potential landmine in D is transient ranges... but I'll refrain
from going there today. :-P)



 A book with all the goodies inside it would make life easier and get
 people off on the right foot instead of having to learn the hard
 way(it's bad enough with all the weird bugs in D already).


I think part of the problem is that D is still changing -- not as
rapidly as before, as we're trying to stabilize it, but nevertheless
still changing -- so what constitutes as "best practice" today may be
regarded as "don't do this" tomorrow.

One example of this is the recent implementation of templated manifest
constants. What *used* to be recommended practice is to write:

	template hasLength(T) {
		enum hasLength = is(typeof(T.init.length)) &&
				is(T.init.length : size_t);
	}

But now, a new, nicer syntax is recommended:

	enum hasLength(T) = is(typeof(T.init.length)) &&
				is(T.init.length : size_t);

So if you were to ask what was "best practice" in 2.063.2, I'd recommend
the first form above. But once 2.064 is out, it would be the second
form.


T

-- 
Only boring people get bored. -- JM
Aug 27 2013
next sibling parent reply "JS" <js.mdnq gmail.com> writes:
On Tuesday, 27 August 2013 at 21:30:53 UTC, H. S. Teoh wrote:

 On Tue, Aug 27, 2013 at 10:59:40PM +0200, JS wrote:

 There seems to be a lot of stuff D can do but no best 
 practices for
 optimal code(performance or safety).
 
 Someone should write a book about it!


 I think we're aware of that. :) The problem is, nobody has 
 stepped up to
 the plate to far.

 As a general rule, though, I'd say that for the most part, 
 Phobos code
 represents the current D best practices (though I do have to 
 qualify my
 statement that *older* Phobos code may not necessarily meet this
 criterion). Or, at the very least, it serves as a pretty good 
 example of
 what typical D code should look like.

 Now, Phobos is still far from perfect, so others may disagree 
 with my
 suggestion that Phobos code is exemplary D code. I *will* say, 
 however,
 that reading Phobos source code has improved my own D coding 
 style by
 leaps and bounds. It's a rather enlightening experience, and 
 highly
 recommended if you want to master D.

 And I keep repeating myself, but reading Phobos source code is 
 actually
 far less frightening than it sounds.  Standard libraries' 
 source code in
 many programming languages have a reputation for being obscure 
 and
 arcane, and not representative of "normal" code in that 
 language, but
 Phobos is a shining counterexample. It is surprisingly pleasant 
 to read,
 and very much how regular D code should look like (except for a 
 few dark
 corners that, hopefully, will be cleaned up eventually).


The only thing I can say about this is that it would be a lot of 
wasted time for those that just want to start programming in D 
but not use old C thinking. I book that distills a lot of the 
techniques and styles would be better. The only ones can write 
such a book are those that write the phobos code then... I'm sure 
it is a small set of people. Do we have to designate a hitter? 
Kenji seems to be a good candidate!?!?!?!




 e.g., The scope(this) thread... is that something I should 
 start
 doing because it is much safer or what?


 scope(this) isn't implemented yet, only proposed. :)

 Even if it ultimately is rejected, I hope that at least it 
 would have
 helped more people know about the potential pitfalls in object
 creation/destruction. Like floating point arithmetic, it's a 
 lot more
 tricky than it may appear at first glance, and maybe I'll be 
 bold and
 say that most existing code is actually incorrect in this area, 
 it's
 just that the problems don't surface that often.




I saw in that thread the use of scope(failure) in the constructor 
and using delegates handle failures.  I didn't really read the 
thread but saw this when glossing over it and wondered if this 
was the correct way to construct objects or not.



 (Another potential landmine in D is transient ranges... but 
 I'll refrain
 from going there today. :-P)



 A book with all the goodies inside it would make life easier 
 and get
 people off on the right foot instead of having to learn the 
 hard
 way(it's bad enough with all the weird bugs in D already).


 I think part of the problem is that D is still changing -- not 
 as
 rapidly as before, as we're trying to stabilize it, but 
 nevertheless
 still changing -- so what constitutes as "best practice" today 
 may be
 regarded as "don't do this" tomorrow.




An online book that could be modified easily could be used. 
Something like github for books where people could contribute 
would work nicely.


 One example of this is the recent implementation of templated 
 manifest
 constants. What *used* to be recommended practice is to write:

 	template hasLength(T) {
 		enum hasLength = is(typeof(T.init.length)) &&
 				is(T.init.length : size_t);
 	}

 But now, a new, nicer syntax is recommended:

 	enum hasLength(T) = is(typeof(T.init.length)) &&
 				is(T.init.length : size_t);

 So if you were to ask what was "best practice" in 2.063.2, I'd 
 recommend
 the first form above. But once 2.064 is out, it would be the 
 second
 form.


Such an "online book" could deal with versioning issues quite 
nicely. If a specialized book writing site isn't available then 
I'm sure a wiki would work.
Aug 27 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Aug 28, 2013 at 12:24:20AM +0200, JS wrote:

 On Tuesday, 27 August 2013 at 21:30:53 UTC, H. S. Teoh wrote:


[...]

One example of this is the recent implementation of templated
manifest constants. What *used* to be recommended practice is to
write:

	template hasLength(T) {
		enum hasLength = is(typeof(T.init.length)) &&
				is(T.init.length : size_t);
	}

But now, a new, nicer syntax is recommended:

	enum hasLength(T) = is(typeof(T.init.length)) &&
				is(T.init.length : size_t);

So if you were to ask what was "best practice" in 2.063.2, I'd
recommend the first form above. But once 2.064 is out, it would be
the second form.


 
 Such an "online book" could deal with versioning issues quite nicely.
 If a specialized book writing site isn't available then I'm sure a
 wiki would work.


http://wiki.dlang.org/

;-)

Seriously, though, the wiki could use someone who could dedicate some
love and care to it, to get it into a shape that's readily accessible
for newcomers. There's already a section devoted to D-related articles
and a tutorial section with a number of "best practices" articles, but
it's still rather bare and needs more content -- a *lot* more content.


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.
Aug 27 2013
parent "growler" <growlercab gmail.com> writes:
On Tuesday, 27 August 2013 at 22:32:39 UTC, H. S. Teoh wrote:

 On Wed, Aug 28, 2013 at 12:24:20AM +0200, JS wrote:

 On Tuesday, 27 August 2013 at 21:30:53 UTC, H. S. Teoh wrote:


 [...]

One example of this is the recent implementation of templated
manifest constants. What *used* to be recommended practice is 
to
write:

	template hasLength(T) {
		enum hasLength = is(typeof(T.init.length)) &&
				is(T.init.length : size_t);
	}

But now, a new, nicer syntax is recommended:

	enum hasLength(T) = is(typeof(T.init.length)) &&
				is(T.init.length : size_t);

So if you were to ask what was "best practice" in 2.063.2, I'd
recommend the first form above. But once 2.064 is out, it 
would be
the second form.


 
 Such an "online book" could deal with versioning issues quite 
 nicely.
 If a specialized book writing site isn't available then I'm 
 sure a
 wiki would work.


 http://wiki.dlang.org/

 ;-)

 Seriously, though, the wiki could use someone who could 
 dedicate some
 love and care to it, to get it into a shape that's readily 
 accessible
 for newcomers. There's already a section devoted to D-related 
 articles
 and a tutorial section with a number of "best practices" 
 articles, but
 it's still rather bare and needs more content -- a *lot* more 
 content.


 T


snap! :)
Aug 27 2013
prev sibling parent "growler" <growlercab gmail.com> writes:
On Tuesday, 27 August 2013 at 22:24:21 UTC, JS wrote:

[snip]


 Such an "online book" could deal with versioning issues quite 
 nicely. If a specialized book writing site isn't available then 
 I'm sure a wiki would work.



There is the D Wiki...

http://wiki.dlang.org/The_D_Programming_Language

In particular these pages:
http://wiki.dlang.org/Articles
http://wiki.dlang.org/Tutorials
http://wiki.dlang.org/Cookbook (this needs some real TLC)

A recent article I highly recommend is this:
http://wiki.dlang.org/Component_programming_with_ranges

I learned a lot from this as a D!newbie.

It would be great if this Cookbook could get up. Example code 
snippets that are peer reviewed, smaller than a tutorial or 
article. It would be just the thing when you know what you want 
but not sure how to implement it in idiomatic D.

Cheers,
G.
Aug 27 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-27 23:29, H. S. Teoh wrote:


 It is surprisingly pleasant to read,
 and very much how regular D code should look like (except for a few dark
 corners that, hopefully, will be cleaned up eventually).


The fact that there are modules with 35+k lines of code, I would say 
that's a dark room rather than a corner :)

-- 
/Jacob Carlborg
Aug 28 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Aug 28, 2013 at 09:19:24AM +0200, Jacob Carlborg wrote:

 On 2013-08-27 23:29, H. S. Teoh wrote:
 

It is surprisingly pleasant to read, and very much how regular D code
should look like (except for a few dark corners that, hopefully, will
be cleaned up eventually).


 
 The fact that there are modules with 35+k lines of code, I would say
 that's a dark room rather than a corner :)


[...]

lol... well, then, let's get cracking on that pull request to split up
std.algorithm. :)

std.datetime is another dark room, but Jonathan is working on that
already.


T

-- 
What do you get if you drop a piano down a mineshaft? A flat minor.
Aug 28 2013