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.

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

Related    


FolderDiscussions


FrontPage | News | TestPage | MessageBoard | Search | Contributors | Folders | Index | Help | Preferences | Edit

Edit text of this page (date of last change: February 3, 2016 0:35 (diff))