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");
}
