When to refactor or "if it stinks, change it"

Kent Beck and Martin Fowler described the need for refactoring in terms of smells. To quote them: "If it stinks, change it".

It seems Kent had a newborn daughter at the time, so that explains everything.

As there are many different situations when the code "stinks", Martin lists them in his "Refactoring" book.

Here is a list adapted and added for iOS and Swift world.



Duplicated code

Functionality should be implemented only once so at any sign of duplicated code, a quick refactoring should be applied to eliminate the duplication.

Large method

Each method should have a limited size, not bigger than one screen, let's say. But more important, than that, one method should do one thing and delegate all the other functionality to other methods.

Large class

Just like methods, a class should not be too large. It is not easy to define a optimal size, a class should have only one aim of existence. If it has more than that, it needs to be split.

Long parameter list

One method should have a limited number of parameters. Ideally is to receive none and to use the properties of the class it is part of. One or two parameters are okay. More than that asks for trouble.

Divergent change

When making a change, the code should be modified just in one area. If for each change, code needs to be modified in separate areas or even separate classes, some refactoring is due.

Feature Envy

This appears when one class uses too much of the the attributes or methods of other class. If that is the case, maybe the methods should be moved into the first class.

Switch or if-else statements

Where there are too much branched code and in many different places, maybe the current class needs to be refactored and different functionality dealt by subclassing.

Lazy class

A lazy class is a class that is not doing much and it is not justifying its existence. In that case, it needs to be eliminated and its functionality move somewhere else.

Message chains

If to work, a class A needs some information from class B that asks C that asks D, then something is not right. Maybe A should ask directly D.

Inappropriate Intimacy

Just like people, classes should not inspect too much other classes private parts (that is properties, some functions, etc.). When that is the case, the intruder needs to behave and mind its own business.

Comments

Comments can be stinky in so many ways. If the are missing, if they are too many, if they exist but are confusing. Funny comments might be funny but not useful (check here).

Confusing names for methods or classes

When a name does not totally explain its owner reason to exist, a new name name needs to be chosen. Adding a comment for a name does not solve the problem.

Not used code, parameter, class etc.

Sometimes functionality is forgotten about and never used. It is time to go.

Ugly code

The code needs to be beautiful as programming is a art (at least so the programers believe). Code can be ugly because the code standards are not respected (or do not exist), naming is inconsistent, the logic is too complex, etc. If so, it needs to be "beautified".

Too many WHF (as per Thom Holwerda)