Refactoring Part 2 – When code starts to smell fishy

• Preparatory Refactoring – Making it easier to add a feature
• Comprehension Refactoring – Making code easier to understand
• Litter-pickup Refactoring
• Planned and opportunistic Refactoring
• Long-Term Refactoring
• Refactoring in a code review

A basic rule of thumb is the rule of three. If you do something similar for the third time, it’s a good opportunity to start refactoring. If a part of the code base is never touched for feature request or for bug fixing, then there is no need for refactoring. But where to start exactly? This can vaguely be determined through experience and good intuition or through “smelly code”.

The term code smell was loosely based on the phrase “If it stinks, change it” from Kent Beck, the creator of extreme programming (XP), quoting his grandmother about diapers. The term was popularised by Martin Fowler’s Book “Refactoring” and describes functional but structurally problematic source code thus indicating a deeper matter. Code smell is vague and its interpretation may differ between developers, but it can be used as a basic value system for the source code and as an indicator for refactoring and which refactoring strategy to use. Smells can be roughly divided into:

• Application-level smells
• Class-level smells
• Method-level smells

A typical application-level smell is duplicated code. Duplicated code may be created due to copy and paste programming by a unexperienced developer and could result worst case in additionally copied vulnerabilities. Refactoring duplications or clones will not only reduce the lines of code but may also positively impact the complexity or the compilation time of the code.

A very large class is an example for a class-level smell. Such a class results in a god or monster object, an object that either knows too much or does too much. Classes like this have other classes and programme code strictly coupled to it which decreases the maintainability.

It is also possible to have too large methods – a method-level smell example – but excessively long or short identifier belong to this category as well. Based on how many identifiers are affected, the naming convention might be the underlying problem.

The first step of the refactoring process should always be to identify the code smell and to have a clear understanding of which part of the source code should be revised. Code smells are good indicators for structural issues within the source code and can, based on the kind of smell, also provide a refactoring strategy to take. In the next article, we will focus on common refactoring strategies and possible pitfalls.