This Week in D January 10, 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

This week had a flurry of activity after the holiday lull, with the biggest change being a redesign of the dlang.org website going temporarily live, but reverted pending a few minor bugs and testing. We expect it will be made permanently live later in the week.

The new design was actually an old design, by Ivan Smirnov, revived by Jacob Carlborg, and implemented by a user going only by anonymous. It is a lighter theme that most the community likes, though it may have been brought live slightly prematurely and will probably have a few more little tweaks going forward, but the redesign will certainly be staying.

In other news, livecoding.tv now supports D tag, showing growing awareness of D!

In the community

Community announcements

See more at the announce forum.

Tip of the Week

This week's tip is not D specific, but one I feel is important: when writing tests, make sure you cover the edge cases.

The main metric I see people talk about with testing, especially in D with its built-in code coverage analyzer via dmd -cov, is the percentage of code lines covered by tests. However, I feel the percentage of the problem domain covered is more important... and harder to automatically measure.

Code coverage will ensure your tests cover the implementation, but will not ensure your tests cover the actual problem. You need to understand the problem well enough to know what the edge cases are where you might have forgotten an important branch in the code.

Make sure you cover various different types of input. If an algorithm depends on chunking, be sure you test it with input of various chunk sizes, including a partial chunk, two chunks, one and a partial chunk, and exactly one chunk. I once wrote an implementation of a hash algorithm that worked on all input... unless the input was exactly 64 bytes long, the length of one chunk. My implementation incorrectly padded it by an extra byte there. The unit tests covered all the code... but the code didn't cover the full problem domain.

Similarly, no date/time library is complete without checking the times right around daylight saving transitions and leap years.

I saw a URL library with a lot of tests that looked good and had 100% coverage, but never implemented nor tested //domain.com/file.html links, which are common on the web.

The list goes on. Don't mistake fully tested code with a fully tested solution. Having a comprehensive knowledge of the problem and relevant background is necessary to write correct tests as well as correct code. Take your time to see a variety of real world and apply as much contextual knowledge as you can when writing tests.

Learn more about D

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