In software, a code smell is not pleasant. Aside from obvious hygiene and social considerations, in much the same way a strong and unpleasant body odor may be the surface indicator of a deeper medical problem, a strong and unpleasant code odor may be the symptom of even relevant weaknesses in the code design. Should we be worried about code odor? A code smell is not the same as a bug. More simply, a code smell is a piece of code that we perceive as not right, but don’t fix right away. Code smells primarily affect the maintain ability of a software system, and any code is almost immediately in need of maintenance as soon as it’s written. Code smells have fancy names and apply to different coding scenarios. This session reviews different code smells and many other aspects of the code, such as factories, data grouping, null pointers, special types, you want to refactor for the sake of readability and easier maintenance.

1. Refactoring and Code Smells
Dino Esposito

2. Smells and 7 Gold Virtues
 Code smells
 The Simple Case of Special Strings
 Join Data that Want to Go Together
 Readability
 Every class begins with a “new”
 Let’s talk dependency injection
 Null pointers
 You Ain’t Gonna Use It

3. Code Smells
 In software, a code smell is not pleasant
 Should we be worried about code odor?
 A code smell is not the same as a bug
 It’s a piece of code that we perceive as not right, but don’t fix right away
 Code smells affect the maintainability of a software system
 Any code is almost immediately in need of maintenance as soon as it’s written

4. Code Smells
 Method-level Code Smells
 Class-level Code Smells
 General Code Smells


5. Method-level Code Smells
• Dead code
• Lazy method
• Middle man
• God method
• Long parameters list
• Contrived complexity
• Cyclomatic complexity
• Inappropriate intimacy
• Feature envy
• Black sheep

6. Class-level Code Smells
• Lazy object
• Middle man
• God method
• Primitive obsession
• Tell-don’t-ask
• Indecent exposure
• Inappropriate intimacy
• Refused bequest
• Speculative generality
• Temporary field

7. General Code Smells
• Lost intent
• Oddball solution
• Combinatorial explosion
• Duplicated code
• Contrived complexity
• Solution sprawl
• Divergent change
• Shotgun surgery
• Deodorant comments
• Data clumps

8. The Simple Case of Special Strings
• “Value Object”
• No identity
• Represented by the
data it holds
• Close to real-world
public class Email
{
public Email(string email)
{
if (string.IsNullOrWhiteSpace(email))
throw new InvalidDataException();
Address = email;
}
public string Address { get; }
public string GetServer()
{
var index = Address.IndexOf("@", StringComparison.Ordinal);
return index > 0
? Address.Substring(0, index)
: Address;
}
}

9. The Simple Case of Special Strings
• “Value Object”
• No identity
• Represented by the
data it holds
• Close to real-world
public class Email
{
public Email(string email)
{
if (string.IsNullOrWhiteSpace(email))
throw new InvalidDataException();
Address = email;
}
public string Address { get; }
public string GetServer()
{
var index = Address.IndexOf("@", StringComparison.Ordinal);
return index > 0
? Address.Substring(0, index)
: Address;
}
}

10. Join Data that Want to Go Together

11. Readability
 ToString method
 Extension methods
 Fixed sets of values (enums, const, ad hoc classes)
 Avoid queries, primitives, hide checks in aptly named methods
var editMode = (request.Id > 0);
var editMode = request.IsInEditMode();

12. Every Class Begins with a “new”
 Constructors are natural to use as everyone learns object-oriented
programming from constructors, but they are hardly business-specific
 In DDD, you only create instances if you have a business reason
 Factory methods make it easier
 Stay closer to the ubiquitous language of the business domain,
 If too many static methods, group your factory methods into an
embedded factory class.

13. Dependency Injection
 Loosely coupled code is not code that works in a standalone context or
in a disconnected software island
 Loosely coupled code is simply code where connections exist, but are
strictly ruled and occur under the umbrella of clear contracts
 Service Locator vs. Dependency Injection
 IoC framework just make DI simpler (much simpler)

14. Null Pointers
 Null checking is boring and doubtless every developer will find a way
to forget one at some point
 “My billion-dollar mistake” said Sir Hoare, inventor of Quicksort
 The main issue with null references is that once the language allows
references to be null, well, any reference can find its way to be null
 Nullability in C# (only value types) and Kotlin (any type)
 Native syntax for safe calls (also in C#)
 Null doesn’t refer to any domain-specific state
 In any business ubiquitous language there’s nothing like null, like a non-value

15. You Ain’t Gonna Need It
 Unreachable code
 Detected by smart editors
 In order to improve readability dead code should be investigated and
eliminated if it’s dead beyond any reasonable doubt
 “Commented out code always work” (cit.)
 Unused branches, but also includes unused parameters in used
methods, unused variables, and private methods never invoked
 Have a smart tool to help you
 In large codebases is a great help

16. Thoughts?