I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
As a general rule, I do find that it is often better to refactor in small steps like this, at least while you're working on things, for three reasons:
It makes it easier to keep track of what's actually happening (especially important for code review).
It makes it easier to track down what change accidentally introduced a bug.
It lets you test the changes incrementally as you go along, making it easier to spot bugs before they happen.
Sometimes though, it really does make sense to just do it all at once because the intermediate states are either nonexistent or just plain meaningless. Switching the internals of a function from an iterative implementation to a recursive one is an example of something like this, there's just no sensible 'intermediate' state for such a change, so it makes no sense to try and step through one.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As a general rule, I do find that it is often better to refactor in small steps like this, at least while you're working on things, for three reasons:
Sometimes though, it really does make sense to just do it all at once because the intermediate states are either nonexistent or just plain meaningless. Switching the internals of a function from an iterative implementation to a recursive one is an example of something like this, there's just no sensible 'intermediate' state for such a change, so it makes no sense to try and step through one.