Last update February 3, 2016

Best Practices

This page describes the "best way" to do things in the D Programming Language. If you have a different opinion, add a comment making your argument.

This page is largely obsolete and needs to be updated

If you have recommendations for good coding practice, please add it.

Table of contents of this page

Order of Import Statements

Portability and Performance

Conventional Module Name for Importing All Modules in a Package

Compiler switches

Exceptions

Related

Order of Import Statements

As an aid to maintainability, discoverability and possible automation, it would be helpful to have a simple import ordering convention? Specifically:

imports from std come first. Root-level comes first, followed by in alphabetical order for sub-levels
an empty line comes next
imports from third-party come next. Root-level comes first, followed by in alphabetical order for sub-levels
an empty line comes next
imports from other modules in "this" organisation/project/library come last. Root-level comes first, followed by in alphabetical order for sub-levels

An example:

 import std.loader;
 import std.utf;
 import std.c.windows.windows;

 import mango.blah;
 import mango.stuff;
 import mango.abc.otherstuff;
 import mango.things.nicethings;

 public import mylib.stuff
 public import mylib.badthings.hmm;
 public import mylib.goodstuff.garbage;

adapted from NG:digitalmars.D/3942

Portability and Performance

On code created today for 32-bit CPUs that may need to be used on 64-bit or larger CPUs in the future.

per Walter from the D forum ( NG:digitalmars.D/5792): For a loop index, you should use 'size_t'. This is because the offset to a pointer will increase in size on 64 bit machines. size_t is defined in object.d. --MarkT

The D spec defines int as a signed 32 bit integer. As of DMD 0.77, size_t is "an alias for an unsigned integral type spanning the address space" -- AndyFriesen

Conventional Module Name for Importing All Modules in a Package

In Java, if you want to import all of the modules in a package, you'd do this:

 import javax.swing.*;

Since D doesn't have a "*" (and it's unlikely that D would get such a shortcut), this capability could be added to a class by adding a module, that imports the other modules. So what should such a module be called. There have been a few suggestions.

all.d
api.d
main.d (already used by dig)
package_name.d

Personally, I like "all.d".

 import mylibrary.mypackage.all;

It's always short and clean, and it almost sounds like a keyword (but it's not). -- JustinCalvarese

Compiler switches

Never ever make a library or a program that requires additional compiler switches! If your library/program depends on another library use pragmas ( D 1.x, D 2.x) and versions ( D 1.x, D 2.x).

An example:

version(Windows) {

   version(Win64) {
      pragma(lib, "foo64.lib");
   } else {
      pragma(lib, "foo32.lib");
   }

}

Windows, Win64, Win32 and linux are predefined. See version.html for more ( D 1.x, D 2.x).

Some of you should remember C++ and the hassles that it sometimes requires when the code is written assuming this and that. I've seen libraries that need to compile with some switches but others require different and then it all goes down hill from there. It also makes it harder for automated tools like DSSS.

Exceptions

When creating your own Exception provide the these two default constructor signatures. This will allow the file and line of the throwing function to be forwarded by those creating a new instance of the Exception:

    this(string msg, string file = __FILE__, size_t line = __LINE__, Throwable next = null)
    {
        super(msg, file, line, next);
    }

    this(string msg, Throwable next, string file = __FILE__, size_t line = __LINE__)
    {
        super(msg, file, line, next);
    }

[BestPractices/DLL Writing DLLs]
Kulkasku/DLL Writing DLLs
Kameraku/DLL Writing DLLs

FolderDiscussions