[Dlang-internal] DMD Technical Debt

[Iain Buclaw]

On Friday, 23 February 2018 at 08:11:41 UTC, Walter Bright wrote:
> DMD Technical Debt
>
> As what happens with all long term projects, code accumulates 
> cruft and technical
> debt. People often ask what to do to improve things, so here's 
> a list:
>

If you don't mind, I'll as some side notes / technical points.


> 6. 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();
}
---


> 14. Avoid clever code. Anybody can write clever code. It takes 
> genius to write simple code.
>

14b. Rather than taking the approach of "first make it work, then 
make it pretty", try to go for the second stage when making a PR.

I can not stress this enough when it comes to making the language 
implementation as cross-platform independent as possible.

> 17. Try to eliminate reliance on `global.errors`.
>

17b. Try to elimate reliance on global gagging.

>
> 21. The more constrained the scope of a name is, the shorter it 
> should be.
>
>

22. Try not to ask questions such as "am I Windows and 64bit?" in 
the decision making process of semantic analysis, instead ask 
questions like "do I reverse the vtable array?", which doesn't 
tie itself to any particular platform, or lock an implementing 
compiler to an ABI which is incompatible to the one its targeting.


23. 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.


>
> Keep in mind that nearly all of this technical debt is MY fault.
>
> As always, treating the above as sacred writ is a huge mistake. 
> Use
> your best judgement on a case-by-case basis. Blindly doing 
> things just
> adds more technical debt.

I will add an extra note here, "this seems to work" counts as 
blindly doing things.


Iain.