Best practices

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Aug 27 14:29:17 PDT 2013


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


More information about the Digitalmars-d mailing list