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.

Code Smells

2,542 views

Published on

Software Craftsmanship: smells in code

Published in: Technology
  • Be the first to comment

Code Smells

  1. 1. Software Craftsmanship Code Smells
  2. 2. Software Craftsmanship Manifesto “Not only working software, but also well- crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships”
  3. 3. Technical Debt Software Finance Skipping (or deferring) design Borrowing money Refactoring (i.e. behavior-preserving design improvements) Repaying principal Slower development due to code smells Paying interest
  4. 4. Code Smells • Lost Intent • Inefficient Name • Duplicated Code • Deodorant Comment • Long Method • Large Class • Lazy Class More…
  5. 5. Lost Intent Just as a traffic sign may be obscured by shrubs, Code that doesn't easily communicate it's author's intention is hazardous: hard to understand, extend and modify.
  6. 6. Lost Intent Intention-Revealing Code Lost Intent The purpose of the code is clear. Low-level or complex logic obscures the code's purpose. You can easily find the code you seek. The location of code makes little sense. Every step of an algorithm is clearly defined. The steps of the algorithm are blended together.
  7. 7. Lost Intent
  8. 8. Inefficient Name Where The Streets Have No Name
  9. 9. Inefficient Name tmp = finder.fetch("0182901"); Account theAccount = finder.fetch(transaction.getSource()); account = finder.fetch( new StateMatcher("VA") ); for(Account item : finder.fetchAll()) { … } getDrctn() getDir() getDirection() These are five lines chosen at random from a class. Each is grabbing a fetch result and putting it in a variable of type Account.
  10. 10. Duplicated Code If you see the same code structure in more than one place, you can be sure that your program will be better if you find a way to unify them. — Refactoring[page 76], Martin Fowler and Kent Beck
  11. 11. Duplicated Code
  12. 12. Deodorant Comment Comments often are used as a deodorant. — Refactoring [page 87], Martin Fowler and Kent Beck
  13. 13. Deodorant Comment
  14. 14. Comment Guidelines • Whenever possible make your code express the intent of the comment and remove the comment. • Comments are to provide intent that is not expressible in code. • Any comment that duplicates what the code says should be deleted.
  15. 15. Long Method A long method is too much to digest
  16. 16. Long Method
  17. 17. Large Class Take on too many responsibilities
  18. 18. Large Class WebServicesProviderContoller • performValidationCB() • executeBusinessProcessCB()
  19. 19. Lazy Class A lazy class isn't doing enough to justify its existence.
  20. 20. Lazy Class
  21. 21. Lazy Class Employee constructor . Passing Jobs in Employee constructor.
  22. 22. Oddball Solution When a problem is solved one way throughout a system and the same problem is solved another way in the same system, one of the solutions is the oddball or inconsistent solution.
  23. 23. Oddball Solution
  24. 24. Primitive Obsession Primitive Obsession exists when code solves a problem using a tool that's too simplistic.
  25. 25. Primitive Obsession
  26. 26. Switch Statement Most times you see a switch statement you should consider polymorphism. — Refactoring, Martin Fowler and Kent Beck (page 82).
  27. 27. Switch Statement Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract.
  28. 28. Switch Statement • Not every occurrence of a switch statement (or if...else if...else if... statements) should be replaced with a polymorphic solution.
  29. 29. Speculative Generality You get this smell when people say "Oh, I think we will need the ability to do that someday" and thus want all sorts of hooks and special cases to handle things that aren't required. — Refactoring, Martin Fowler and Kent Beck (page 83).
  30. 30. Speculative Generality
  31. 31. Long Parameter List Methods that take too many parameters produce client code that is awkward and difficult to work with.
  32. 32. Long Parameter List user = userManager.create(USER_NAME, group, USER_NAME, “test", USER_NAME, LANGUAGE, false, false, new Date(), "blah", new Date());
  33. 33. Conditional Complexity Conditional logic is innocent in its infancy, when it is simple to understand and contained within a few lines of code. Unfortunately, it rarely ages well. — Joshua Kerievsky, Refactoring to Patterns, page 41.
  34. 34. Conditional Complexity
  35. 35. Combinatorial Explosion When new combinations of data or behavior further bloat an already bloated design, you've got a Combinatorial Explosion smell.
  36. 36. Combinatorial Explosion
  37. 37. Alternative Classes With Different Interfaces This subtle smell results when differences in the interfaces of similar classes leads to duplicated code.
  38. 38. Alternative Classes With Different Interfaces
  39. 39. Inappropriate Intimacy Sometimes classes become far too intimate and spend too much time delving in each others' private parts. — Refactoring [page 85], Fowler and Beck
  40. 40. Inappropriate Intimacy
  41. 41. Indecent Exposure We don't normally expose wires inside a wall or ceiling.
  42. 42. Indecent Exposure
  43. 43. Refused Bequest Subclasses get to inherit the methods and data of their parents. But what if they don't want or need what they are given? — Refactoring[page 87], Martin Fowler and Kent Beck
  44. 44. Refused Bequest
  45. 45. Black Sheep
  46. 46. Black Sheep
  47. 47. Solution Sprawl When code and/or data used to perform a responsibility becomes sprawled across numerous classes, Solution Sprawl is in the air. — Joshua Kerievsky, Refactoring to Patterns, page 43.
  48. 48. Solution Sprawl
  49. 49. Feature Envy
  50. 50. Feature Envy
  51. 51. Temporary Field An object's field (a.k.a. instance variable) should have meaning during the full lifetime of the object.
  52. 52. Temporary Field
  53. 53. Side Effect
  54. 54. Side Effect
  55. 55. References • Refactoring: Improving the Design of Existing Code by Martin Fowler • Refactoring to Patterns by Joshua Kerievsky. • https://elearning.industriallogic.com/gh/subm it?Action=AlbumContentsAction&album=reco gnizingSmells&devLanguage=Java

×