[dmd-internals] Refactorings of dmd

[Walter Bright via dmd-internals]

On 5/22/2015 10:16 AM, Daniel Murphy wrote:
> Could you please identify some refactorings that you feel are useless?
>   I've been the author of many large refactorings needed for DDMD, and
> I suspect you making yourself the bottleneck for refactorings is going
> to be a huge pain.  If you feel contributors have been merging pull
> requests without adequate review please let us know.
>

I have pulled the ones you needed for DDMD, and I pulled them because it was 
necessary in order to make DDMD work.

Of course it's a judgement call, but refactorings that are not productive share 
one or more of these characteristics:

1. potatoe potahto name changes
2. indentation/whitespace/reformatting
3. the number of lines of code increases
4. re-ordering functions in a file
5. moving code from one file to another
6. large diffs with no seeming point to them
7. large diffs that are not reviewable because github diff is unhelpful with 
figuring out what actually changed
8. make dmd slower

Essentially, refactorings that "bounce the rubble" around are going to be viewed 
negatively.

Refactorings that would be viewed with favor:

1. identifying significant common code sequences out and consolidating into 
reusable functions
2. better encapsulation
3. more logical flow of control
4. reduction in cyclomatic complexity
5. move towards making functions pure

For example, I recently did a small refactor that replaced argc/argv manual 
memory management with the Strings type. It removed a bunch of code, and the 
rest flowed a lot better.

I've pulled a lot of refactorings. My concern with this is the large increase in 
regressions. Those refactorings should be reducing regressions - but it seems 
that at best they are not helping, and at worst are making things worse. I'm 
also concerned that people are not working on the real problems with DMD, and 
instead are doing refactorings. We have a lot of open regressions, and no 
proposed fixes for them. But we've got refactorings regularly appearing. I know 
that refactorings are more fun than regression fixes. But we've got to get the 
bread and butter work done.

And lastly, I am swamped with work. I'm the only one working on range fixes for 
Phobos - fixes that I have been advocating for a couple years now, and nobody 
has done anything to move this forward. So I am doing it. This range-ification 
is, quite frankly, absolutely critical to D's future success. I must get it 
done. But I get bogged down in interminable reviews of refactorings with 
hundreds of lines of rubble bouncing.