Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

.NET Fest 2018. Dino Esposito. Refactoring and Code Smells

19 views

Published on

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.

Published in: Education
  • Be the first to comment

  • Be the first to like this

.NET Fest 2018. Dino Esposito. Refactoring and Code Smells

  1. 1. Refactoring and Code Smells Dino Esposito
  2. 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. 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. 4. Code Smells  Method-level Code Smells  Class-level Code Smells  General Code Smells 
  5. 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. 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. 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. 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. 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. 10. Join Data that Want to Go Together
  11. 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. 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. 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. 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. 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. 16. Thoughts?

×