• Walter Bright (15/15) Sep 20 2018 I've learned this the hard way, and I've had to learn it several times b...
• Peter Alexander (5/8) Sep 20 2018 I find this is a great procedure for any sort of large
• Patrick Schluter (11/19) Sep 21 2018 Also, use a git commit for each logical change. If you discover a
• rjframe (3/9) Sep 21 2018 I'd add 4b: file an issue for anything that needs to be fixed; otherwise...

Walter Bright <newshound2 digitalmars.com> writes:

I've learned this the hard way, and I've had to learn it several times because
I 
am a slow learner. I've posted this before, and repeat it because bears
repeating.

The procedure is:

1. pass the test suite
2. prep the file for conversion, i.e. try to minimize the use of idioms that 
won't easily translate
3. pass the test suite
4. translate the code with as few edits as practical. Do not reformat the code. 
Do not refactor it. Do not fix anything, no matter how tempting. Reproduce the 
behavior of the original as much as possible.
5. pass the test suite
6. now reformat, refactor, fix (as separate PRs, of course, and passing the
test 
suite in between each).
7. pass the test suite

Note that without a test suite, you're doomed :-)

Peter Alexander <peter.alexander.au gmail.com> writes:

On Friday, 21 September 2018 at 06:00:33 UTC, Walter Bright wrote:
 I've learned this the hard way, and I've had to learn it 
 several times because I am a slow learner. I've posted this 
 before, and repeat it because bears repeating.

I find this is a great procedure for any sort of large 
refactoring -- minimal changes at each step and ensure tests are 
passing after every change.

Thanks for sharing!

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

On Friday, 21 September 2018 at 06:24:14 UTC, Peter Alexander 
wrote:
 On Friday, 21 September 2018 at 06:00:33 UTC, Walter Bright 
 wrote:
 I've learned this the hard way, and I've had to learn it 
 several times because I am a slow learner. I've posted this 
 before, and repeat it because bears repeating.

 I find this is a great procedure for any sort of large 
 refactoring -- minimal changes at each step and ensure tests 
 are passing after every change.

Also, use a git commit for each logical change. If you discover a 
change that should have been put in a previous commit, use rebase 
--interactive to put it in right commit (of course that branch 
you're working on is purely local). Only when all the changes 
have been made can you decide to squash or not, or reorder them, 
or push them partially.

TL;DR

git can help to organize the refactoring, not be solely a 
recording device.

rjframe <dlang ryanjframe.com> writes:

On Thu, 20 Sep 2018 23:00:33 -0700, Walter Bright wrote:

 The procedure is:
 ...
 4. translate the code with as few edits as practical. Do not
 reformat the code. Do not refactor it. Do not fix anything, no matter
 how tempting. Reproduce the behavior of the original as much as
 possible.

I'd add 4b: file an issue for anything that needs to be fixed; otherwise 
it's quickly forgotten.