Dos and Don'ts in D

Posted 2023-10-30

A reader emailed me this week asking if I could make a simple list of dos and don'ts based on my experience. I'll do that here, and even edit this post later if more ideas come to mind.

Core D Development Statistics

In the community

Community announcements

See more at the announce forum.

Dos and Donts for D

These are based on my personal experience and opinions, but these come from having worked with a lot of D code. There are exceptions to every rule, but by definition, you're probably not an exception.

  • DO always use a multi-part name for your modules. This helps avoid name conflicts when using multiple libraries.
  • DON'T use custom version specifiers. Try enum bool and static if instead of version=x declarations. Consider using a configuration module instead of command line -version arguments.
  • DO remember your fundamentals. So often, new D users get so excited about templates, mixins, etc., that they reach for them where a simple, plain function would do the job just as well.
  • DON'T use std.format at compile time, nor ~= loops. They're very slow, unless the string is very small. Preallocate the string and slice-copy components into it instead.
  • DO favor /++ +/ comments over the others. They're really convenient for multiline and can nest, making it easier to do more documentation and examples inside them.
  • DON'T waste your time with the attribute soup. The return-on-investment just isn't there.
  • DON'T use package.d. It is a poorly designed, buggy mess. (Added Nov 2, 2023)
  • DON'T use selective imports (meaning prefer import std.conv; over import std.conv : to;) unless you are solving a specific name conflict. The implementation of this is janky can can lead to surprising results. (Added Nov 6, 2023)
  • DON'T use alias predicates. Phobos embraced this paradigm, but it actually brings a lot of trouble - dual context issues, template bloat, and more. Instead, use regularly typed delegates. You lose attribute inference on the delegate but attributes aren't worth it anyway. (Added Nov 8, 2023)
  • DO accept D as it is, warts and all. If you start using it thinking things will be fixed later, you'll probably be frustrated. If you try to fix things yourself, you'll *definitely* be frustrated. (Added Nov 11, 2023)
  • DON'T use dub's sourceLibrary target type. It doesn't work once you become a diamond dependency. (Added Dec 11, 2023).

I'll come back and edit this list if more things come up, or if I write associated articles I can link in for more details.