This Week in D January 31, 2016

Welcome to This Week in D! Each week, we'll summarize what's been going on in the D community and write brief advice columns to help you get the most out of the D Programming Language.

The D Programming Language is a general purpose programming language that offers modern convenience, modeling power, and native efficiency with a familiar C-style syntax.

This Week in D has an RSS feed.

This Week in D is edited by Adam D. Ruppe. Contact me with any questions, comments, or contributions.

Statistics

Major Changes

DMD 2.070.0 was released this week. It includes the official packaging of the new win32 bindings.

In the community

Community announcements

See more at the announce forum.

Tip of the Week

Today, I want to write about comments. Yes, what code does should be easy to see from the name or the code itself. But why it is doing that is an entirely different story and that's where comments are uniquely useful.

Everybody knows /* add one to i */ i += 1; is useless. Even /* skip past closing character */ i += 1; is arguably best written as skipPastClosingCharacter(); or whatever.

But we shouldn't say "you shouldn't need comments" just because i += 1 is easy to read because there can still be a legitimate question: Why is it there? Why do we need to skip past the closing character? Why isn't it done elsewhere?

/* findCloser leaves us on the closing character but we don't want to process it */
i += 1;

That's quite a bit more interesting now.

/* returns the remainder, including the closing character, so you can test what it was */
function findCloser() {}

Now the reader understands the rationale for this choice and can take that into consideration when they go to fix "bugs" (is it a bug or did you just not understand the purpose?) or refactor or whatever.

Working on Github recently, I've seen a lot of this happen in github comments. That sucks! (Actually, I think most github comments ought to be replaced with code edits, but that's another story.) When someone is reading the new file, they won't see github comments, and they can be pretty hard to find even if you go hunting with blame and whatnot. But they will see code comments, and they will be right there, in full context.

If you are writing code and anticipate a reviewer to ask a question, don't email them. Comment the code with the answer! Or any other place where a reader might say "why?" or "I think I'm going to change this" and you think they shouldn't, comment that.

Learn more about D

To learn more about D and what's happening in D: