How to Find the Stinky Parts of Your Code (Part II)

Written by mcsee | Published 2020/10/30
Tech Story Tags: pixel-face | code-smells | clean-code | stinky-code-parts | refactor-legacy-code | refactoring | stinky-code | common-code-smells | web-monetization

TLDRvia the TL;DR App

There are more code smells. Let’s keep changing the aromas. We see several symptoms and situations that make us doubt the quality of our development. Let's look at some possible solutions.
Most of these smells are just hints of something that might be wrong. They are not rigid rules.
This is part II. Part I can be found here, Part III here, Part IV and Part V.

Code Smell 06 - Too Clever Programmer

The code is difficult to read, there are tricky with names without semantics. Sometimes using language's accidental complexity.
Image Source: NeONBRAND on Unsplash
Problems
  • Readability
  • Maintainability
  • Code Quality
  • Premature Optimization
Solutions
  1. Refactor the code
  2. Use better names
Examples
  • Optimized loops
Exceptions
  • Optimized code for low-level operations.
Sample Code
Wrong
Right
Detection
Automatic detection is possible in some languages. Watch some warnings related to complexity, bad names, post increment variables, etc.
Also Known as
  • Obfuscator
  • Conclusion
    Too clever developers write cryptic code to brag. Smart developers write clean code. Clean beats clever, every time.
    Tags
  • Declarative
  • Code Smell 07 - Boolean Variables

    Using boolean variables as flags expose accidental implementation and pollutes the code with Ifs.
    Image Source: Phil Hearing on Unsplash
    Problems
    • Extensibility
    • Comparison in some languages
    Solutions
    If Boolean maps to a real-world entity it's safe. Otherwise model as a State to favor Extensibility. This also follows Open/Closed Principle.
    Examples
    • Flags
    Exceptions
  • Real-world true/false rules
  • Sample Code
    Wrong
    Right
    Detection
    Automatic detection can warn for boolean usage but this can yield false positives.
    Relations
    Some languages have issues with boolean comparators.
    If these are coupled with accidental complex languages, booleans are a common error source.
    Also Known As
  • Flag Abuser
  • Tags
    • Declarative
    • Primitive
    Conclusion
    Take extra care when declaring something boolean. Flags are difficult to maintain and extend. Learn more about the domain or try migrating to state design pattern. Use polymorphism instead of ifs/switch/cases.

    Code Smell 08 - Long Chains Of Collaborations

    Making long chains generate coupling and ripple effect. Any chain change breaks the code.
    Image Source: Chewy on Unsplash
    Problems
    • Coupling
    • Breaks encapsulation
    Solutions
    1. Create intermediate methods.
    2. Think about Law of Demeter.
    3. Create higher level messages.
    Sample Code
    Wrong
    Right
    Detection
    Automatic detection is possible using parsing trees.
    Also Known As
  • Law of Demeter
  • Tags
    • Declarative
    • Encapsulation
    Conclusion
    Avoid successive message calls. Try to hide the intermediate collaborations and create new protocols.

    Code Smell 09 — Dead Code

    Code that is no longer used or needed.
    Image Source: Ray Shrewsberry on Pixabay
    Problems
    • Maintainability
    Solutions
    1. Remove the code
    2. KISS
    Examples
    • Gold plating code or Yagni code.
    Exceptions
    Avoid metaprogramming. When used it is very difficult to find references to the code.
    Sample Code
    Wrong
    Right
    Detection
    Coverage tools can find dead code (uncovered) if you have a great suite of tests.
    Tags
    • Unnecessary
    Conclusion
    Remove dead code for simplicity. If you are uncertain of some code you can temporarily disable it using Feature Toggle. Removing code is always more rewarding than adding.

    Code Smell 10 — Too Many Arguments

    Objects or Functions need too many arguments to work.
    Image Source: Tobias Tullius on Unsplash
    Problems
    • Low maintainability
    • Low Reuse
    • Coupling
    Solutions
    1. Find cohesive relations among arguments
    2. Create a “context”.
    3. Consider using a Method Object Pattern.
    4. Avoid “basic” types: strings, arrays, integers, etc. Think about objects.
    Exceptions
    • Operations in real world needing not cohesive collaborators.
    Sample Code
    Wrong
    Right
    Detection
    Most linters warn when the arguments list is too large.
    Tags
    • Primitive
    Conclusion
    Relate similar arguments and group them. Always favor real-world mappings. Find in the real-world how to group the arguments in cohesive objects.
    If a function has too many arguments, some of them might be related to the class construction. This is a design smell too.
    That's all for now! More code smells coming soon!

    Written by mcsee | I’m senior software engineer specialized in declarative designs and S.O.L.I.D. and Agile lover.
    Published by HackerNoon on 2020/10/30