Cure

---

This illness is extremely common, and therefore you are likely to encounter its effects when working with other programmers’ code. You might also encounter it in old code that you have written. First, let us look at when you should correct this problem, and then we can go into the proper techniques for refactoring.

When to Refactor

There are several reasons that can require the refactoring of a complex algorithm into a simpler algorithm. Let us look at each of them in turn. The first and most obvious reason for refactoring is when the algorithm is no longer meeting the requirements for which it was chosen. Algorithms that are more complex tend to also be more restrictive in their focus and therefore can easily become obsolete with changing requirements. When this occurs, it is also a good time to evaluate the requirements to see if they can be loosened to prevent future refactoring of the same sort from occurring. Regardless, there is no choice in this situation but to refactor.

Another extremely compelling reason to refactor a complex algorithm comes at the end of development in the optimization phase. The added complexity can often cost processing power. In many cases, requirements can be traded off for improved performance by replacing the complex algorithm with a simpler algorithm that requires less processing. As always, remember that this type of decision should only occur during the optimization phase to avoid Premature Optimization.

An opportunity for refactoring that is often overlooked occurs when the algorithm needs a minor modification. When confronted with the need to modify a complex algorithm, look at the requirements and context of the algorithm and determine if there is a prospect of simplifying the algorithm. If you do find that the algorithm can be simplified, this will not only make your modification easier, but also make any future modifications less time consuming. On average, this should work out to an increase in productivity that offsets the small amount of extra time spent in the short term.

Another useful reason for refactoring a complex algorithm is to come to a better understanding of the effects of the algorithm and how it operates. In this case, you might not end up simplifying the algorithm at all, but if not, you will, at that point, understand why it could not be simplified. You will also gain an understanding of the algorithm that can help if any modifications are required.

Simplify the Algorithm

The first step in refactoring a problem caused by Complexification is to choose a simpler algorithm to use. This process is much the same as we talked about in preventing Complexification, but there are a couple of extra considerations. Since an algorithm already exists, you must check to see if there is other code that depends on the algorithm in ways not specified by the requirements. In essence, this implicitly makes the requirements stricter. Before you can relax these requirements, you must learn what they are. Once you understand the unspecified requirements, you can then decide if they can be relaxed. In this case, if you want to relax them you must refactor the code to remove the dependencies before performing the refactoring to remove the Complexification.

Even if there are no implicit requirements, it is quite possible that the interface of the simpler algorithm will differ from the complex algorithm’s interface. This refactoring should also be performed first. This ensures that the old algorithm’s interface can be made to match to the new algorithm’s interface. By doing this, it ensures that the algorithms will not alter the intended functionality.

Simplify the Code

Once you have implemented the new algorithm, it is important to also clean up the code. The first step should be to remove dead code from the new implementation. Dead code comes in two primary forms. The first and most obvious dead code is code that will no longer be executed under any circumstances with the new implementation. The second form of dead code is less obvious and has a much more detrimental effect on the readability of the code. This takes the form of code that is called but performs no work; in other words, it produces no change in the program state and no visible effect to the user. Examples of this form are temporary variables that are assigned but never used, and private functions with arguments that have the same value in all calls.

Code of both forms and any associated comments should be removed from the application completely. At this point, many argue that they might use the code again, or that they will need to refer to the code in the future. However, if you are using a source control system, this older code can be stored in earlier revisions without cluttering the present state of the code. If you are not using a source control system, you should be. At the very minimum, CVS is a freely available version control system that has been ported to many platforms. It is also useful to have a set of graphical tools, such as WinCVS for CVS, which allow you to browse the code history. With the use of a source control system, the reasons for simply commenting out the code or leaving it are greatly outweighed by the poor readability that the dead code causes.

The process of refactoring can also cause names and comments to become confusing, meaningless, or plain wrong. Each comment should be checked and updated if necessary, and any names that do not seem clear should be renamed. This might seem like a considerable amount of work, but doing it consistently will save you time when you make the inevitable changes that will need to be made.

---