More code smells. No joke. 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 . here here here here part V VI VII VIII IX Let's continue... Code Smell 46 — Repeated Code DRY is our mantra. Teachers tell us to remove duplication. We need to go beyond. Photo by on Sid Balachandran Unsplash Problems Code Duplication Maintainability Don’t Repeat Yourself Solutions Find repeated patterns (not repeated code). Create an abstraction. Parametrize abstraction calls. Use composition and never inheritance. Unit test new abstraction. Sample Code Wrong Right Detection Linters can find repeated code. There are not very good finding similar patterns. Maybe soon machine learning will help us find such abstractions automatically. For now, it is up to us, humans. Examples Automatic Code Generators Tags Duplication Conclusion Repeated code is always a smell. Copying and pasting code is always a shame. With our refactoring tools, we need to accept the duplication remove challenge trusting our tests as a safety net. More info Don't Repeat Yourself Copy and paste is a design error. David Parnas Code Smell 47 — Diagrams Diagrams are not code. They cannot be a code smell. They are just Diagram Smells. Photo by on Nick Seagrave Unsplash Problems Maintainability Trash code Code Duplication Diagrams focus only on structure (accidental) and not behavior (essential). Solutions Use diagrams only to communicate ideas with other humans. Program on your favorite IDE.Thrash all diagrams. Even the ones generated from the source code. Trust your tests. They are alive and well maintained. Use technique. Domain Driven Design Sample Code Wrong Right Detection We can remove all code annotations and forbid them by policy. Examples Automatic Code Generators Conclusion Designing is a contact sport. We need to prototype and learn from our running models. Papers and JPGs don’t run. They live in the utopic world where everything works smoothly. was a very hot trend back in the 90s. No good system was developed with these tools. CASE More info Laziness Chapter II: Code Wizards Computer Aided Sofwtare Engineering Domain Driven Design 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 48 — Code Without Standards Working on a solo project is easy. Unless you go back to it after some months. Working with many other developers requires some agreements. Photo by De Jesus de Blas — Russia Problems Maintainability Readability Solutions Automate your styles and indentation. Enforce agreed policies. Sample Code Wrong Correct sample taken from Sandro Mancuso’s bank kata Right The right example has several other smells, but we keep it loyal to its GIT version in order to show only code standardization issues. Detection Linters and IDEs should test coding standards before a merge request is approved. We can add our own related to Objects, Classes, Interfaces, Modules etc. naming conventions Examples PSR2 Tags Standardization Conclusion Use coding standards in your projects. A well-written clean code always follows standards about naming conventions, formatting and code style. Such standards are helpful because they make things clear and deterministic for the ones who read your code, including yourself. Code styling should be automatic and mandatory on large organizations to enforce . Collective Ownership More info What Exactly Is A Name: The Quest [Part I] The nice thing about standards is that there are so many to choose from. Andrew S. Tannenbaum Code Smell 49 — Caches Caches are sexy. They are a one-night stand. We need to avoid them in a long-term relationship. Photo by on Aimee Vogelsang Unsplash Problems Coupling Testability Cache invalidation. Maintainability Premature Optimization Erratic Behavior Lack of transparency Non-Deterministic behavior Solutions If you have a conclusive benchmark and are willing to pay for some coupling: Put an object in the middle. Unit test all your invalidation scenarios. Experience shows we face them in an incremental way. Look for a real world cache metaphor and model it. Sample Code Wrong Right Detection This is a design smell. It will be difficult to enforce by policy. Tags Premature Optimization Conclusion Caches should be functional and intelligent. In this way we can manage invalidation. General purpose caches are suitable only for low level objects like operating systems, files and streams. We shouldn’t cache domain objects. This page is hosted on a cached website. More Info What is Cache and Why do New Devs Struggle With It? A Hitchhiker’s Guide to Caching Patterns There are only two hard things in Computer Science: cache invalidation and naming things. Phil Karlton Code Smell 50 — Object Keys Primary keys, IDs, references. The first attribute we add to our objects. They don’t exist in the real world. Photo by on Maurice Williams Unsplash Problems Coupling Accidental Implementation Violation. Bijection Principle Solutions Reference to . object objects Build a . MAPPER Only use keys if you need to provide an external (accidental) reference. Databases, APIs, Serializations. Use dark keys or when possible. GUIDs If you are afraid of getting a big relation graph use proxies or lazy loading. Don’t use DTOs. Sample Code Wrong Right Detection This is a design policy. We can enforce business objects to warn us if we define an attribute or function including the sequence . id Tags Accidental Conclusion Ids are not necessary for OOP. You reference objects (essential) and never ids (accidental). In case you need to provide a reference out of your system’s scope (APIs, interfaces, Serializations) use dark and meaningless IDs (GUIDs). More info What is (wrong with) software? The One and Only Software Design Principle The nice thing about standards is that there are so many to choose from. David Wheeler We are done for some time. But we are pretty sure we will come across even more smells very soon! 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 X)

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

Too Long; Didn't Read

Company Mentioned

@mcsee

RELATED STORIES