Best practices

[JS]

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.