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
next sibling 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
parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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 next sibling 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 "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