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.
