Skip to content

Instantly share code, notes, and snippets.

@cyyeh

cyyeh/bad_smells_in_code.md

Last active May 26, 2022 12:11
Show Gist options
  • Save cyyeh/3cb10a1e84036e6fb0b0eae37a1bc54a to your computer and use it in GitHub Desktop.
Save cyyeh/3cb10a1e84036e6fb0b0eae37a1bc54a to your computer and use it in GitHub Desktop.
Download ZIP
bad smells in code
Raw
bad_smells_in_code.md

Bad Smells in Code

Notes: you need to have the Refactoring: Web Edition account in order to see details of Refactoring Strategies

Table of Contents

  1. Mysterious Name
  2. Duplicated Code
  3. Long Function
  4. Long Parameter List
  5. Global Data
  6. Mutable Data
  7. Divergent Change
  8. Shotgun Surgery
  9. Feature Envy
  10. Data Clumps
  11. Primitive Obsession
  12. Repeated Switches
  13. Loops
  14. Lazy Element
  15. Speculative Generality
  16. Temporary Field
  17. Message Chains
  18. Middle Man
  19. Insider Trading
  20. Large Class
  21. Alternative Classes with Different Interfaces
  22. Data Class
  23. Refused Bequest
  24. Comments
  25. References

1. Mysterious Name

2. Duplicated Code

3. Long Function

4. Long Parameter List

5. Global Data

6. Mutable Data

7. Divergent Change

8. Shotgun Surgery

9. Feature Envy

  • The fundamental rule of thumb is to put things together that change together. Data and the behavior that references that data usually change together—but there are exceptions. When the exceptions occur, we move the behavior to keep changes in one place. Of course, there are several sophisticated patterns that break this rule. From the Gang of Four, Strategy and Visitor immediately leap to mind. Kent Beck’s Self Delegation is another. Use these to combat the divergent change smell.
  • Refactoring Strategies

10. Data Clumps

11. Primitive Obsession

12. Repeated Switches

13. Loops

14. Lazy Element

15. Speculative Generality

16. Temporary Field

17. Message Chains

18. Middle Man

19. Insider Trading

20. Large Class

21. Alternative Classes with Different Interfaces

  • One of the great benefits of using classes is the support for substitution, allowing one class to swap in for another in times of need. But this only works if their interfaces are the same
  • Refactoring Strategies

22. Data Class

  • Data classes are often a sign of behavior in the wrong place, which means you can make big progress by moving it from the client into the data class itself
    • Exceptions
      • the intermediate data structure after you've applied Split Phase: A key characteristic of such a result record is that it's immutable (at least in practice). Immutable fields don't need to be encapsulated and information derived from immutable data can be represented as fields rather than getting methods
  • Refactoring Strategies

23. Refused Bequest

24. Comments

  • The reason we mention comments here is that comments are often used as a deodorant. It’s surprising how often you look at thickly commented code and notice that the comments are there because the code is bad.
  • Our first action is to remove the bad smells by refactoring. When we’re finished, we often find that the comments are superfluous.
  • A good time to use a comment is when you don’t know what to do. In addition to describing what is going on, comments can indicate areas in which you aren’t sure. A comment can also explain why you did something. This kind of information helps future modifiers, especially forgetful ones.
  • Refactoring Strategies

25. References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment