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.
Functionality should be implemented only once so at any sign of duplicated code, a quick refactoring should be applied to eliminate the duplication.
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.
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.
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.
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.
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.
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.
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 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.
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)
Post a Comment
Note: Only a member of this blog may post a comment.