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.

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?

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)?

These are my questions and none of them are intended as flamebait… These are practical thoughts I always encounter whenever approaching a new language/development environment. Language documentation seldom answers these types of questions.

Best Regards,
Stefan Larsson

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

http://dlang.org/dstyle.html )))

DUB like other tools have a standard directory layout to accelerate a build process/configuration.

DStyle and other guide lines are general recommendations only. If you have better style/case, you can describe and use it.

On 2013-09-29 07:49:08 +0000, Jonathan M Davis said:

> 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

There are two reasons for this as I see it:

1. It makes it easier for myself to write code in a consistent style and I would automatically write in a similar style as everybody else. It removes one degree of freedom from my mind.

2. It simplifies education of teams where it is desired that all members write code in the same style/layout. In my opinion it should not be possible to see which individual wrote the code.

I guess I have been using too much LaTeX through the years where the final look of the document is the same regardless of the writer given that the same document class is used. :)

----8<----------

/Stefan Larsson

Stefan Larsson:

> 1. It makes it easier for myself to write code in a consistent style and I would automatically write in a similar style as everybody else. It removes one degree of freedom from my mind.
>
> 2. It simplifies education of teams where it is desired that all members write code in the same style/layout. In my opinion it should not be possible to see which individual wrote the code.

Having a shared coding style in a newly designed language is quite important.
This is an introduction to the standard D style:
http://dlang.org/dstyle.html

Regarding tools for that, there are not many at the moment, like:
http://analyzed.no-ip.org/
But probably this tool should be improved in its perceptions of what good D is.

Bye,
bearophile

On Sunday, 29 September 2013 at 07:49:21 UTC, Jonathan M Davis wrote:
> 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

I think nowadays programmers expect their language to come with more opinion and best practices. In contrast, the C++ world is too fragmented for consistent advice.

I believe, the best solution would be to include an auto-formatter (like go fmt), so people can simply reformat the code before and after editing.

On Tuesday, 1 October 2013 at 19:32:08 UTC, qznc wrote:
> On Sunday, 29 September 2013 at 07:49:21 UTC, Jonathan M Davis wrote:
>> 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
>
> I think nowadays programmers expect their language to come with more opinion and best practices. In contrast, the C++ world is too fragmented for consistent advice.
>
> I believe, the best solution would be to include an auto-formatter (like go fmt), so people can simply reformat the code before and after editing.

That may be, but we are not working with C++, python, Go, etc programmers. We are dealing with D programmers, and they can't agree on formatting. There are also many cases which require breaking rules for readability.

For me, if the program didn't format brackets on the same line I wouldn't use it. If you start making things configurable, may as well improve indent's support for D.

On Wednesday, October 02, 2013 03:19:19 Jesse Phillips wrote:
> On Tuesday, 1 October 2013 at 19:32:08 UTC, qznc wrote:
> > On Sunday, 29 September 2013 at 07:49:21 UTC, Jonathan M Davis
> > 
> > wrote:
> >> 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
> > 
> > I think nowadays programmers expect their language to come with more opinion and best practices. In contrast, the C++ world is too fragmented for consistent advice.
> > 
> > I believe, the best solution would be to include an auto-formatter (like go fmt), so people can simply reformat the code before and after editing.
> 
> That may be, but we are not working with C++, python, Go, etc programmers. We are dealing with D programmers, and they can't agree on formatting. There are also many cases which require breaking rules for readability.

Yeah. Even if you like the rules that a formatting tool uses, it's never smart enough. Inevitably, you have to break the rules in some places to make the code appropriately legible. In some respects, formatting is more of an art than a science, and automatic formatters of course treat it as if it worked to have strict rules with no exceptions, and it doesn't, not if you want your code to look good.

> For me, if the program didn't format brackets on the same line I wouldn't use it. If you start making things configurable, may as well improve indent's support for D.

Whereas I'd hate to have to write code that didn't have braces on their own line. It's far better for us both to be able to write code the way that we want than try and force standard formatting rules of some kind. IMHO, they add little to no value and definitely make coding less enjoyable.

- Jonathan M Davis

On Tuesday, October 01, 2013 21:32:05 qznc wrote:
> On Sunday, 29 September 2013 at 07:49:21 UTC, Jonathan M Davis
> 
> wrote:
> > 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
> 
> I think nowadays programmers expect their language to come with more opinion and best practices. In contrast, the C++ world is too fragmented for consistent advice.
> 
> I believe, the best solution would be to include an auto-formatter (like go fmt), so people can simply reformat the code before and after editing.

Yuck. I want to be able to format my code the way that I like. I really don't like the idea of any kind of standard formatting, and I hate it when I'm forced to work on projects where I'm forced to format the code in a particular way. I'd much, much rather be able to format the code however I like. I've worked on several projects where the rule of thumb is to try and keep the formatting with a file consistent but otherwise let folks format their code how they like, and that's far more pleasant IMHO. Having a formatter just encourages forcing some sort of standard format, and it only works for the folks who really like that format and the folks who don't care about formatting.

- Jonathan M Davis

On Wednesday, 2 October 2013 at 03:28:59 UTC, Jonathan M Davis wrote:
> On Wednesday, October 02, 2013 03:19:19 Jesse Phillips wrote:
>> For me, if the program didn't format brackets on the same line I
>> wouldn't use it. If you start making things configurable, may as
>> well improve indent's support for D.
>
> Whereas I'd hate to have to write code that didn't have braces on their own
> line. It's far better for us both to be able to write code the way that we
> want than try and force standard formatting rules of some kind. IMHO, they add
> little to no value and definitely make coding less enjoyable.

My vision: Jonathan checks out Jesses code to fix a bug. On opening the file his editor automatically reformats to braces-on-own-line. When committing the fix, a pre-commit hook reformats to the project-specific style braces-on-same-line. Everybody is happy. :)

Of course, there are edge cases, where automatic formatting should be broken. However, I think we should let them be and adapt. I also add code sometimes, just to remove a compiler warning like "unused argument". Likewise, I am fine with minor noise in exchange for consistent styling like described above.