dlang / dmd

• Many archaic C-style for loops can be replace straightforward with a foreach
• Instead of pointers, D's arrays can be used
• Use distinct variable names for non-overlapping uses
• add attributes (const/nothrow/pure/scope/@safe/private/etc.)
• Rename the return value variable to result
• Use ref instead of raw pointers
• "Shrinkwrap" the scope of local variables as tightly as possible around their uses.
• Use nested functions to get rid of rats' nests of goto's.
• Declare local variables as const as much as possible.
• Avoid use of mutable globals as much as practical. Consider passing them in as parameters.
• Avoid use of default parameters - Spell them out.
• Minimize use of overloading
• Reduce reliance on global.errors and global gagging
• Reduce cyclomatic complexity (i.e. think about how to make the code work without control flow statements.)

Use Single Assignment for local variables:

T t = x;
...
t = y;

becomes:

T tx = x;
...
T ty = y;

Look for duplicative code and factor out into functions.

One easy win here are visitor functions that return a result.

Instead of having code like this all over the place:

if (foo)
{
    this.result = e;
    return;
}
else
{
    this.result = new ErrorExp();
    return;
}

Make it a function!

if (foo)
    return setResult(e);
else
    return errorExp();

// (Names of functions are just explanatory) ...

void setResult(Expression e)
{
    this.result = e;
}

void errorExp()
{
    this.result = new ErrorExp();
}

Ideas and PRs that improve DMD's tooling

https://github.com/dlang/DIPs

https://dlang.org/deprecate.html

Add descriptive prefixes

• 'is' is the parameter in a certain category?
• 'has' does the parameter have a certain feature?
• 'can' for can I do X with the parameter?

Such functions should not be mutating the data nor issuing error messages.

Don't mix mutating vs. state checking functions

Try not to mix functions that "answer a question" with functions that "mutate the data". See escape.d for an example.

Remove reliance on public fields

For aggregates that expose public access to fields, think hard about why this is necessary and if it can be done better. Merely replacing them with read/write properties accomplishes nothing. The more of its internal details can be made private, the better.

Remove extern(C++) / public methods

Consider what is currently a public or extern(C++) method or function, and try to make it private or extern(D). The backend / glue layer doesn't need all access to the front-end AST. And having a stable API / abstraction layer would ultimately mean less breakages between C++ <-> D boundaries.

• Do not use Ddoc comments for overrides unless the overriding function does something different (as far as the caller is concerned) than the overridden function.
• Ddoc comment blocks are often overkill for nested functions and function literals; use ordinary comments for those.

See also: https://github.com/dlang/dmd/pull/7893

Motivated from @WalterBright's comment here: http://forum.dlang.org/post/p2pdn5$8dm$1@digitalmars.com

See also Bugzilla:

• https://issues.dlang.org/buglist.cgi?quicksearch=error%20message&list_id=220788 (search query: "error message")
• https://issues.dlang.org/buglist.cgi?keywords=diagnostic%2C%20&keywords_type=allwords&list_id=220789&query_format=advanced&resolution=--- (all issues labelled with diagnostics)

A collection of open challenges.