• Stefan Larsson (44/44) Sep 29 2013 Hello,
• Jonathan M Davis (23/63) Sep 29 2013 I confess that I don't understand why so many people are fixated on havi...
• Stefan Larsson (13/41) Sep 29 2013 There are two reasons for this as I see it:
• bearophile (11/18) Sep 30 2013 Having a shared coding style in a newly designed language is
• qznc (8/16) Oct 01 2013 I think nowadays programmers expect their language to come with
• Jesse Phillips (8/24) Oct 01 2013 That may be, but we are not working with C++, python, Go, etc
• Jonathan M Davis (12/40) Oct 01 2013 Yeah. Even if you like the rules that a formatting tool uses, it's never...
• qznc (12/25) Oct 02 2013 My vision: Jonathan checks out Jesses code to fix a bug. On
• Jonathan M Davis (9/37) Oct 02 2013 Personally, I don't think that that's particularly realistic, but it's f...
• John Colvin (3/5) Oct 02 2013 I'm guessing you don't use druntime or phobos then :p
• Jonathan M Davis (12/31) Oct 01 2013 Yuck. I want to be able to format my code the way that I like. I really ...
• Stefan Larsson (4/18) Oct 17 2013 You could also store the code not as text but as a datastructure like a
• Michael (5/5) Sep 29 2013 http://dlang.org/dstyle.html )))
• Gary Willoughby (11/17) Oct 18 2013 When i first started using D i found the two biggest barriers to

Stefan Larsson <stefan lastsys.com> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

Stefan Larsson <stefan lastsys.com> writes:

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

"bearophile" <bearophileHUGS lycos.com> writes:

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

"qznc" <qznc web.de> writes:

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.

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

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.

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

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

"qznc" <qznc web.de> writes:

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.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Wednesday, October 02, 2013 10:38:10 qznc wrote:
 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. :)

Personally, I don't think that that's particularly realistic, but it's far 
from the first time that someone has suggested that sort of thing. And giving 
the inherent flaws in code formatters, I think that this sort of thing is 
doomed to failure.

 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.

Whereas I care way more about being able to format code the way I want than I 
do about consistent styling.

But code formatting is arguably very much a flamebait topic.

- Jonathan M Davis

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Wednesday, 2 October 2013 at 01:19:21 UTC, Jesse Phillips 
wrote:
 For me, if the program didn't format brackets on the same line 
 I wouldn't use it.

I'm guessing you don't use druntime or phobos then :p

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

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

Stefan Larsson <stefan lastsys.com> writes:

On 2013-10-01 19:32:05 +0000, qznc said:

 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.

You could also store the code not as text but as a datastructure like a 
parse tree. Then the editing environment is free to handle this 
information the way it wants...

"Michael" <pr m1xa.com> writes:

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.

"Gary Willoughby" <dev nomad.so> writes:

On Sunday, 29 September 2013 at 07:13:26 UTC, 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...

When i first started using D i found the two biggest barriers to 
entry were UFCS and D's Template syntax. Luckily i've covered 
both on my blog to give newcomers a quick leg up. Andrei's book 
is great and very thorough but without the two points above being 
explained fully the first half can be confusing.

http://nomad.so/2013/07/templates-in-d-explained/
http://nomad.so/2013/08/alternative-function-syntax-in-d/

These are explained later in the book but examples use them long 
before they are covered.