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

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 of something that might be wrong. They are not rigid rules. hints Code Smell 01 — Anemic Models Your objects are a bunch of public attributes without behavior. Photo by on Stacey Vandergriff 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’ Problems No Encapsulation. No to real world entities. mapping Duplicate Code Coupling Solutions 1) Find Responsibilities. 2) Protect your attributes. 3) Hide implementations. 4) Delegate Examples DTOs Sample Code Wrong Right Detection Detection can be automated with sophisticated linters ignoring setters and getters and counting real behavior methods. Also Known as Data Class Tags Anemic OOP as Data Encapsulation Setters/Getters Mutability More info: Wikipedia Refactoring Guru Nude Models — Part I : Setters Nude Models — Part II : Getters How to Decouple a Legacy System Code Smell 02 — Constants and Magic Numbers A method makes calculations with lots of numbers without describing their semantics. Photo by on Kristopher Roller Unsplash Problems Coupling Low testability Low readability Repeated Code Solutions 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. Examples Algorithms Hyper Parameters Sample Code Wrong Right Detection Many linters can detect number literal in attributes and methods. Tags Hard coded Constants Repeated Code More info Wikipedia Refactoring Guru How to Decouple a Legacy System Code Smell 03 — Functions Are Too Long Humans get bored beyond line 10. Photo by on Hari Panicker Unsplash Problems Low Cohesion High coupling Difficult to read Solutions 1) Refactor 2) Create small objects dealing with some of the tasks. Unit test them. 3) Compose methods Examples Libraries Sample Code Wrong Right Detection All linters can measure and warn when methods are larger than a predefined threshold. Also Known as Long Method More info Refactoring Guru Tags Complexity Code Smell 04 — String Abusers Too many parsing, exploding, regex, strcomp, strpos and string manipulation functions. Photo by on Nathaniel Shuman Unsplash Problems Complexity Readability Maintainability Lack of Abstractions Solutions 1) Work with objects instead. 2) Replace strings with data structures dealing with object relations. 3) Go back to Perl :) 4) Find problems between real objects and the strings. Bijection Examples Serializers Parsers Sample Code Wrong Right Detection Automated detection is not easy. A warning can be issued if too many string functions are used. Relations Primitive Obsession Tags Mapping Code Smell 05 — Comment Abusers Code has lots of comments. Comments are coupled to implementation and hardly maintained. Photo by on Volodymyr Hryshchenko Unsplash Problems Maintainability Obsolete Documentation Solutions 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. Examples: Libraries Class Comments Method Comments Sample Code: Wrong Right Detection: Linters can detect comments and check the ratio comments / lines of code against a predefined threshold. More info Refactoring.Guru What is a Name: Part I Tags Comments Declarative To be continued... How to Find the Stinky Parts of Your Code (Part II) How to Find the Stinky Parts of Your Code (Part III) How to Find the Stinky Parts of Your Code (Part IV) How to Find the Stinky Parts of Your Code (Part V) … and many more to come. Smells are certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring. Martin Fowler 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.