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 , Part II , Part III is , Part IV , and (for now). here here here here part V the last one Let's continue... Code Smell 31 — Accidental Methods on Business Objects Adding persistence, serialization, displaying, importing, exporting code to an object bloats its protocol and brings coupling. Photo by Robert Bye on Unsplash Problems Readability Coupling Maintainability Solutions Keep your objects clean. Decouple business objects. Separate accidental concerns: Move Persistence, Formatting, Serialization to special objects. Keep essential protocol using . bijection Examples Persistence Identifiers Serialization Formatting Sample Code Wrong Right Detection It is difficult (but not impossible) to create linting rules based on naming and hinting for suspect names. Exceptions Some frameworks force us to inject dirty code in our objects. (For example identifiers). We should try to use better languages/frameworks. Tags Declarative Conclusion We are very used to see business objects polluted. This is normal. We need to reflect on the consequences and coupling from these designs. Simple things should be simple, complex things should be possible. Alan Kay Code Smell 32 — Singletons The most used and (in)famous design pattern in the world is causing us great harm. Photo by Maria Teneva on Unsplash Problems Coupling Testability Accidental implementation problems. Multi threading issues. Static methods polluting. Object creation contract violation. mismatch. Bijection Memory issues. Premature Optimization. Solutions Avoid it. Use contextual unique objects. Benchmark object creation. Examples Database Access Globals Loggers Helpers Sample Code Wrong God is the archetypical singleton example. Right Detection This is a design pattern. We should avoid it by policy. We can add linter rules for patterns like so new developers cannot infect code with this . ‘getInstance()’ anti-pattern Tags Globals Conclusion This is an historical mistake already acknowledged by the community. Nevertheless, lazy developers bring it again and again. We need to reach a consensus on its drawbacks. The Diagram is Not the Model. The model is not the diagram. It is an abstraction, a set of concepts and relationships between them. Eric Evans Code Smell 33 — Abbreviations Abbreviating is very important so that we look smart and save memory and mind space. Photo by Jessica Knowlden on Unsplash Problems Coupling Bad Naming Declarativeness Ambiguity Readability Premature Optimization Solutions Use meaningful and names. declarative Examples Variable naming Function naming Package naming Class Naming Sample Code Wrong Right Detection We can’t automate choosing what is a name and a . short declarative Some “modern” and shinny languages enforce this bad practice. So we should wisely choose a good language instead. Tags Declarative Conclusion Computer science was born from the mother of science (mathematics). In math, the assignment of single letter variables is a good practice. (i, j, x, y) The concept of reference arose from the variable. Many people wondered why mathematicians can work with such short variables, and computer scientists cannot. For mathematicians, once entered into a formula, variables lose all semantics and become indistinguishable. Our brain wastes a lot of energy figuring out what is the meaning of an abbreviation. It is 2020, We need to write software for humans, not for compilers. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment. Robert Martin Code Smell 34 — Too Many Attributes A class defines objects with lots of attributes. Photo by Andy Li on Unsplash Problems Low Cohesion Coupling Maintainability Readability Solutions Find methods related to attributes. Cluster these methods. Break the object related to those clusters. Find real objects related to this new objects and replace existing references. Examples DTOs Denormalized table rows Sample Code Wrong Right Detection Most linters warn when you declare too many attributes. Setting a good warning threshold should be easy. Tags primitive Conclusion Bloated objects know too much and are very difficult to change due to cohesion. Developers change these objects a lot, so they bring merge conflicts and are a common problems source. So much complexity in software comes from trying to make one thing do two things. Ryan Singer Code Smell 35 — State as Properties When an object changes its state the best solution is to change the attribute, isn’t it? Photo by Tom Crew on Unsplash Problems Mutability Attributes polluting Setters Solutions Model states as mathematical set inclusion. State is accidental, take it away from the object. Examples State diagrams Sample Code Wrong Right Detection If we want to be extreme, we should consider every to be a potential state change. Linters can warn us. But we might end up getting too many false positives. setter Exceptions Over Design Performance issues (if a serious benchmark supports it). Tags Mutation Conclusion This technique is very elegant but can lead to over design. For example changing a visual component's color should be a counterexample to this smell. We should be aware and very caution like with any other smell. They are and not rigid rules. hints First make the change easy (warning: this might be hard), then make the easy change. Kent Beck Those were the first 35. Nevertheless, I keep getting more suggestions on , so they won't be the last! twitter

Twitter

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Nominated for 2022 - HackerNoon Contributor of the Year - Refactoring

Nominated for 2022 - HackerNoon Contributor of the Year - Quality Assurance

Nominated for 2022 - HackerNoon Contributor of the Year - Github

Nominated for 2022 - HackerNoon Contributor of the Year - Machine Learning

Nominated for 2022 - HackerNoon Contributor of the Year - Clean Code

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Nominated for 2022 - the Greatest Storyteller

Nominated for 2022 - HackerNoon Contributor of the Year - Debugging

Software Engineer

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

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

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

Too Long; Didn't Read

People Mentioned

Company Mentioned

@mcsee

RELATED STORIES