How to Find the Stinky Parts of Your Code (Part I) | Hacker Noon

Author profile picture

@mcseeMaximiliano Contieri

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

The code smells bad. Let’s see how to change the aromas. In this series, we will see several symptoms and situations that make us doubt the quality of our developments. We will present possible solutions. Most of these smells are just hints of something that might be wrong. They are not rigid rules.

Code Smell 01 — Anemic Models

Your objects are a bunch of public attributes without behavior.

Photo by Stacey Vandergriff on Unsplash

Protocol is empty (with setters/getters).

If we ask a domain expert to describe an entity he/she would hardly tell it is ‘a bunch of attributes’.

  • No Encapsulation.
  • No mapping to real world entities.
  • Duplicate Code
  • Coupling
  • 1) Find Responsibilities.
  • 2) Protect your attributes.
  • 3) Hide implementations.
  • 4) Delegate

Wrong

Right

Detection can be automated with sophisticated linters ignoring setters and getters and counting real behavior methods.

  • Data Class
  • Anemic
  • OOP as Data
  • Encapsulation
  • Setters/Getters
  • Mutability

A method makes calculations with lots of numbers without describing their semantics.

Photo by Kristopher Roller on Unsplash

  • Coupling
  • Low testability
  • Low readability
  • Repeated Code
  • 1) Rename the constant with a semantic and name (meaningful and intention revealing).
  • 2) Replace constants with parameters so you can mock them from outside.
  • 3) The constant definition is often a different object than the constant (ab)user.
  • Algorithms Hyper Parameters

Wrong

Right

Many linters can detect number literal in attributes and methods.

  • Hard coded
  • Constants
  • Repeated Code

Humans get bored beyond line 10.

Photo by Hari Panicker on Unsplash

  • Low Cohesion
  • High coupling
  • Difficult to read
  • 1) Refactor
  • 2) Create small objects dealing with some of the tasks. Unit test them.
  • 3) Compose methods

Wrong

Right

All linters can measure and warn when methods are larger than a predefined threshold.

  • Long Method
  • Complexity

Too many parsing, exploding, regex, strcomp, strpos and string manipulation functions.

Photo by Nathaniel Shuman on Unsplash

  • Complexity
  • Readability
  • Maintainability
  • Lack of Abstractions
  • 1) Work with objects instead.
  • 2) Replace strings with data structures dealing with object relations.
  • 3) Go back to Perl 🙂
  • 4) Find Bijection problems between real objects and the strings.
  • Serializers
  • Parsers

Wrong

Right

Automated detection is not easy. A warning can be issued if too many string functions are used.

  • Primitive Obsession

    Photo by Volodymyr Hryshchenko on Unsplash

    • Maintainability
    • Obsolete
    • Documentation
    • 1) Refactor methods.
    • 2) Rename methods to more declarative ones.
    • 3) Break methods.
    • 4) If a comment describe what a method does, name the method with this description.
    • 5) Just comment important designs decisions.
    • Libraries
    • Class Comments
    • Method Comments

    Wrong

    Right

    Linters can detect comments and check the ratio comments / lines of code against a predefined threshold.

  • Comments
  • Declarative

… and many more to come.

Part of the objective of this series of articles is to generate spaces for debate and discussion on software design.

We look forward to comments and suggestions on this article.

Tags

read original article here