Some small style rules for D user code:

1) All variables and functions arguments should be immutable/const (or enum), unless they have to mutate (or there is some other problem in Phobos, in the D type system, or in your other code).

2) The code should contain as few cast() as possible. [*]

3) Where possible it's better to use foreach() instead of for() loops.

4) for/foreach/while loops are not evil, but it's better to use map/filter/zip where possible and where performance allows them.

5) Functions/methods should be pure and nothrow where possible.

- - - - - - -

[*] The D type system (and Phobos) should be improved to help reduce their frequency. Some of the enhancement requests I have written on that:

http://d.puremagic.com/issues/show_bug.cgi?id=10018  (By Lionello Lunesu)
http://d.puremagic.com/issues/show_bug.cgi?id=10594
http://d.puremagic.com/issues/show_bug.cgi?id=10615
http://d.puremagic.com/issues/show_bug.cgi?id=10685
http://d.puremagic.com/issues/show_bug.cgi?id=10749
http://d.puremagic.com/issues/show_bug.cgi?id=10751

More not-too-much-hard-to-implement ideas are welcome.

Bye,
bearophile

On Monday, 5 August 2013 at 13:01:19 UTC, bearophile wrote:
> Some small style rules for D user code:
>
> 1) All variables and functions arguments should be immutable/const (or enum), unless they have to mutate (or there is some other problem in Phobos, in the D type system, or in your other code).
>
> 2) The code should contain as few cast() as possible. [*]
>
> 3) Where possible it's better to use foreach() instead of for() loops.
>
> 4) for/foreach/while loops are not evil, but it's better to use map/filter/zip where possible and where performance allows them.
>
> 5) Functions/methods should be pure and nothrow where possible.
>
> - - - - - - -
>
> [*] The D type system (and Phobos) should be improved to help reduce their frequency. Some of the enhancement requests I have written on that:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=10018  (By Lionello Lunesu)
> http://d.puremagic.com/issues/show_bug.cgi?id=10594
> http://d.puremagic.com/issues/show_bug.cgi?id=10615
> http://d.puremagic.com/issues/show_bug.cgi?id=10685
> http://d.puremagic.com/issues/show_bug.cgi?id=10749
> http://d.puremagic.com/issues/show_bug.cgi?id=10751
>
> More not-too-much-hard-to-implement ideas are welcome.
>
> Bye,
> bearophile


Those tips are rather helpful to me as a developer who started learning D just before 1 month. I would really like to see more of those and it will be good to be put on the front page or somewhere visible so newcomers can see it. It will be just some text document full of small tips and conventions that define the D-style. Because D is very flexible language and it offers different types of syntax it will be good to define when to use one or another. For example, when you specify declaration attributes there are 3 different ways of doing it.

Tips I want to add about module imports:

6) When declaring imports follow the following convention:
    1. Specify the module name | module fancymodule.functions;
    2. Import all std modules | import std.stdio;
    3. Import all external library modules | import dsfml.system;
    4. Import all modules part of your project | import fancymodule.actions;
    * Have a module named 'all' that only publicly imports all of your library's modules:
        module fancymodule.all;
        public {
            import fancymodule.functions;
            import fancymodule.actions;
        }

        * Others prefer to name that module the same name as the library | module fancymodule.fancymodule;
        * And others name it 'd' | module fancymodule.d;
    * Use scoped imports if you want to use only one or two functions from a module only in one 'scoped' place(in a function body etc.) in your module:
        void fun() {
            import std.stdio;
            writeln("fancy!");
        }
    * Use version(unittest) imports to import modules that are used only in your unittests | version(unittest) import std.exception;
    * Use selective imports when you use only one or two members from a module | import std.stdio : write, writeln;
    * Use static imports when some of the module members have name conflicts with your module members or can be easily confused with some of your module logic:
        static import std.math; //or renamed: static import math = std.math;
        //some scope {
        auto sin = std.math.sin(std.math.PI); //will be confusing to have: auto sin = sin(PI);
        //}
    * For the above cases if you prefer to instead use renamed selective imports:
        import math = std.math : sine = sin;
        //some scope {
        auto sin = sine(math.PI); //PI is not in the selective import list of math so it has to be explicitly accessed. You can think of selective imports as static imports that allow some members not to be specified explicitly(Correct me if I'm wrong)
        //}
    * If you have a name conflict, then use static imports(or renamed module-only static imports if the module name is too long) instead of renamed imports. So that others who read your code don't get confused for the new name:
        static import io = std.stdio; //instead of: import std.stdio : puts = writeln
        void writeln(T...)(T args) {
            io.write(args);
            io.writeln("fancy endline");
        }

I made a markdown gist for the above module import tips:
https://gist.github.com/nikibobi/6156492

On 08/05/2013 03:01 PM, bearophile wrote:
> 2) The code should contain as few cast() as possible. [*]

What about to!() ... ?  Is it possible to gain the performance of cast() while
using to!() ... ?

> 4) for/foreach/while loops are not evil, but it's better to use map/filter/zip where possible and where performance allows them.

Your remarks about performance here are apt.  Maps, filters etc. make for very elegant code but as we discussed, there are serious performance issues.

On Mon, Aug 05, 2013 at 03:01:18PM +0200, bearophile wrote:
> Some small style rules for D user code:
[...]

Note that in git HEAD, importing of packages as modules has been implemented via package.d:

	import my.path.module;

will now also work with:

	/my
	/my/path
	/my/path/module
	/my/path/module/package.d
	/my/path/module/implementation1.d
	/my/path/module/implementation2.d

This means the guideline on import a.b.c.all; will soon be obsolete.


T

-- 
Famous last words: I wonder what will happen if I do *this*...

On Monday, August 05, 2013 15:46:13 Joseph Rushton Wakeling wrote:
> On 08/05/2013 03:01 PM, bearophile wrote:
> > 2) The code should contain as few cast() as possible. [*]
> 
> What about to!() ... ? Is it possible to gain the performance of cast()
> while using to!() ... ?

That depends. In general, no. std.conv.to specifically checks stuff like integer overflow, whereas the built-in casts speficilally don't. So, in general, you'll incur a slight performance penalty when using std.conv.to (though exactly how expensive it is depends on what is being converted to what). For a lot of code though, that performance hit will be so negligible, that it won't matter. It _will_ be there though.

- Jonathan M Davis