Learning D - first steps and best practices

[Jonathan M Davis]

On Sunday, September 29, 2013 09:13:26 Stefan Larsson wrote:
> Hello,
> 
> I have started my journey to learn D after using C/C++ and Python for
> many years. I am studying the book "The D-Programming Language" by
> Andrei Alexandrescu and I have tried to search the D-newsgroups for
> proper advice without success and I am humbly seeking enlightenment in
> the following topics:
> 
> 1. ** Coding style **
> When starting out with Python there is general coding style advice
> available in PEP8 (http://www.python.org/dev/peps/pep-0008/) giving
> advice on coding style. For C/C++ I have been using the Google style
> guide (http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml)
> and from Microsoft there are Design Guidelines for Class Library
> Developers
> (http://msdn.microsoft.com/en-us/library/czefa0ke%28v=vs.71%29.aspx). I
> guess Java has similar things.
> For Python there are plugins giving warnings when the coding style is
> not followed forcing me to learn the proposed style.
> Q1a: Are there any material on code standards for D available?
> Personally I believe there should be.

I confess that I don't understand why so many people are fixated on having a 
standard style, particularly when it's very, very clear that most everyone 
disagrees on what counts as good style. What little we have in terms of official 
style guidlelines for D can be found here: http//:dlang.org/dstyle.html

Almost all of it centers on how APIs and very little of it discusses code 
formatting (which is how it should be IMHO).

> 2. ** Build process **
> What is the recommended toolchain for building projects? I have
> previously been using CMake a lot due to ease of platform and compiler
> change, good support for mixed language projects and automatic
> detection of common libraries and its compiler/linker flags. I am
> however getting the impression that dub is recommended for D, but I
> believe it is in its early stages.
> Q2a: So, what is the recommended work process for building a D-project
> when creating a new project?
> Q2b: Given Q2a above, what is a recommended file structure for a large
> D-project? Where should I put third-party library bindings in relation
> to my own code?

Generally, the simplest is to just use rdmd, which comes with the compiler. 
Just use rdmd on the module with main in it, and it'll compile all of its 
dependencies along with it (unlike the compiler, which just compiles what you 
tell it to). However, there's also dub: 
https://github.com/rejectedsoftware/dub

It's a package manager for D which does handle building in a similar fashion 
to rdmd and deals with pulling in any libraries that you depend on. It's 
fairly new, and I expect it to evolve over time, but it works fairly well, and 
it looks like it's going to become D's official package manager.

> 3. ** Quality **
> I see a risk with the (small) dub respository in its current state
> since mostly master branches are used. This means that I might get a
> broken build due to a broken commit in any referenced package.
> Q3a: Are there any efforts taking place regarding stability of packages
> in the community similar to e.g. Debian packaging (stable, testing,
> unstable)?

That's completely up to the folks managing the packages. If you want something 
more stable, then list a branch or tag as your dependency rather than master 
(though that does depend on the person who manages the package actually 
providing branches or tags in the dub repository). dub will also probably be 
improved in the future with regards to how it deals with locking down 
dependency trees.

- Jonathan M Davis