Hackernoon logoHow to Find The Stinky Parts of Your Code (Part VIII) by@mcsee

How to Find The Stinky Parts of Your Code (Part VIII)

image
Maximiliano Contieri Hacker Noon profile picture

@mcseeMaximiliano Contieri

I’m senior software engineer specialized in declarative designs and S.O.L.I.D. and Agile lover.

Yet more code smells? Plenty of!

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 V. Part I can be found here, Part II here, Part III is here, Part IV herepart V and the last one (for now).

Let's continue...

Code Smell 36 - Switch/case/elseif/else/if statements

First programming lesson: Control structures. Senior developer lesson: avoid them.

image

Photo by Adarsh Kummur on Unsplash

Problems:

  • Too many decisions together
  • Coupling
  • Duplicated code
  • Violation of Open/Closed Principle.
  • A new condition should not change the main algorithm.
  • Nulls

Solutions

  1. Polymorphism
  2. Create hierarchies/compose objects following Open closed principle.
  3. Use State pattern to model transitions.
  4. Use Strategy Pattern/Method Object to choose for branches.

Examples

  • Discrete Values
  • State transition
  • Algorithm choice.

Sample Code

Wrong

Right

Detection

Since there are valid cases for If/else usages, we should not pull the plug and forbid these instructions. We can put a ratio of if statements/other statements as a warning instead.

More info

  • How to Get Rid of Annoying IFs Forever
  • NULL: The Billion Dollar Mistake
  • If debugging is the process of removing software bugs, then programming must be the process of putting them in.

    Edsger Dijkstra

    Code Smell 37 - Protected Attributes

    Protected attributes are great for encapsulating and controlling access to our properties. They might be warning us for another smell.

    image

    Photo by Jonathan Farber on Unsplash

    Problems

    Solutions

    1. Favor composition
    2. Don't subclassify attributes.
    3. Extract behavior to separate objects.
    4. Use traits (if available).

    Wrong

    Right

    Detection

    In languages supporting protected attributes we can avoid them by policy or have a warning of this smell.

    Tags

    • Encapsulation

    Conclusion

    Protected attributes are yet another tool we should use carefully. Every decision is a smell, and we should be very careful with attributes and inheritance.

    More Info

    Subclasses shouldn’t always share all characteristics of their parent class but will do so with inheritance. This can make a program’s design less flexible. It also introduces the possibility of calling methods on subclasses that don’t make sense or that cause errors because the methods don’t apply to the subclass.

    Steve Klabnik

    Code Smell 38 - Abstract Names

    Avoid too abstract names. Names should have real world meaning

    image

    Photo by Rodion Kutsaev on Unsplash

    Problems

    • Implementation Naming
    • Meaningless names
    • Broken MAPPER and Bijection to real world entities.

    Solutions

    1. Choose meaningful names.
    2. Find metaphors.
    3. Avoid words like abstractbasegenerichelper etc.
    4. Use rules for naming.

    Sample Code

    Wrong

    Right

    Detection

    We can set up policies and rules warning for certain words like base, abstract, helper, manager, object etc.

    Tags

    • Naming

    Conclusion

    Finding names is the last thing we should do on our designs. Unless we have a clear business understanding, good names emerge at the end after defined behavior and protocol boundaries.

    More info

    There are only two hard things in Computer Science: cache invalidation and naming things.

    Phil Karlton

    Code Smell 39 - new Date()

    70s first tutorial: getCurrentDate(). Piece of Cake. We are in the 20s Time is global no more

    image

    Problems

    • Coupling
    • Fragile Tests
    • Timezone Problems

    Solutions

    1. Use Dependency injection to decouple time source.

    Sample Code

    Wrong

    Right

    Detection

    We should forbid global functions policies. We need to couple to accidental and pluggable time sources.

    Conclusion

    Date.today(), Time.now(), and other global system calls are coupling smell.

    Since tests must be in full environmental control. We should easily set up time, moved it back and forth etc.

    Date and Time classes should only create immutable instances. It is not their responsibility to give the actual time. This violates Single Responsibility Principle.

    The passage of time is always scorned by programmers. This makes objects mutable and designs poor and coupled.

    More info

    Tags

    • Globals
    In programming, the hard part isn't solving problems, but deciding what problems to solve.

    Paul Graham

    Code Smell 40 - DTOs

    Data Transfer Objects (DTOs) are widely used, and they 'solve' real problems, do they?

    image

    Problems

    • Anemic Object
    • Inconsistent Data
    • Duplicated logic
    • Duplicated structure
    • Class Polluting
    • Information Hiding Violation
    • Code repeated among mutators, accessors, serializersparsers
    • Ripple Effect
    • Data integrity

    Solutions

    1. Transfer anemic data on arrays.
    2. Use real business objects.
    3. If we want to transfer partial objects: use proxies or null objects to break the reference graph.

    Sample Code

    Wrong

    Right

    Detection

    We can use the same anemic object detectors.

    We can check for anemic classes with no business object behavior (removing serializes, constructors, mutators etc).

    Tags

    • Anemic

    Conclusion

    DTOs are a tool and an established practice in some languages. We should use them with care and responsibility.

    If we need to disassemble our objects in order to send them away from our realms, we need to be extremely cautioned. Since dismembered objects have no integrity considerations.

    His author warns us about its actual abuse.

    More info

    The best smells are something that's easy to spot and most of time lead you to really interesting problems. Data classes (classes with all data and no behavior) are good examples of this. You look at them and ask yourself what behavior should be in this class.

    Martin Fowler

    Are 40 enough?. When will we stop?

    I keep getting more suggestions on twitter, so they won't be the last!

    Tags

    Join Hacker Noon

    Create your free account to unlock your custom reading experience.