Theoretical Limitations of Refactoring?

deleyd used Ask the Experts™
I wonder, given some program source code, and applying small incremental refactorings, is it always possible to get from any starting code to any other code configuration where the code still retains all the functionality of the original code, or are there valid code configurations which cannot be achieved through refactoring?

For example, starting with code which sorts using Bubble Sort, is it possible to refactor that using small incremental refactorings and end up with a much better sorting algorithm, such as Heapsort or Quicksort?

(I suspect not. I suspect the only way to go from Bubble Sort to Heapsort would be to first analyze the Buble sort code and realize on a higher level what the code is achieving, namely that this bit of code is a "Sorting Algorithm", and then one can replace that sorting algorithm with any other sorting algorithm, but the swap I'm guessing consists of fully replacing the algorithm with a different algorithm which accomplishes the same thing; I'm guessing there are no smaller incremental refactoring steps that could be made without understanding the higher concept of what the code is trying to achieve.)

Is my hunch correct? Has any mathematician examined this to prove what better code configurations are reachable and which ones are not, by using only standard refactoring techniques, without understanding the "goal" of the code?

(I'm kind of fudging because I'm sure someone will say "replace one algorithm with a better one" is a refactoring technique.)
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Eduard GherguArchitect - Coder - Mentor


Refactoring refers to code quality and it should be performed as part of a TDD cycle, so when you have a safety net against changes that are modifying the behavior of the existing code. The algorithm changes are not the subject of refactoring, but of software design and, possibly, architecture (depending on the algorithm). What you can do is to encapsulate your sorting "details" in a component that can offer this service to other components and will hide the implementation details (aka, the algorithm used).
AndyAinscowFreelance programmer / Consultant

Refectoring is not the same as rewriting and redisigning the code.

And yes there is a limit to refectoring - when the code is already optimal any changes will make it worse.
Replacing one algorithm with a better one can be a refactoring technique if the algorithm isn't the final product.

If I have a shipping fleet of bicycles and I want to speed up deliveries, I can swap them out with cars instead. That's refactoring in the real world. I still have a shipping fleet with the same purpose but it's just working faster now.

However, if I have a bicycle and I want a Ferrari, then I can't modify the bicycle to make it into a Ferrari. That's not refactoring - that's just replacement.

If you change the overall end result, then it's not refactoring. If you keep the end result but simply improve how you get there, that's refactoring.

Refactoring without understanding the goal of the code is insanely risky. I would never do such a thing unless the change was so small that I could guarantee it wouldn't change the final result. Other than those situations, just about any change has the capacity to change the final result, so you need to know what that is.

An example of refactoring:
string[] dataList = { "Tom", "Dick", "Harry" };
string result = string.Empty;
foreach (string item in dataList)
	result += dataList + ", ";

//get rid of last ", " in result
result = result.Remove(result.Length - 2, 2);

Open in new window

Refactors into -
string[] dataList = { "Tom", "Dick", "Harry" };
string result = string.Join(", ", dataList);

Open in new window


Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial