There are yet more code smells. Let’s keep changing the aromas. 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 III. Part I can be found and Part II . here here The part IV, and finally . Part V Code Smell 10 — Too Many Arguments Objects or Functions need too many arguments to work Photo by Tobias Tullius on Unsplash Problems Low maintainability Low Reuse Coupling Solutions Find cohesive relations among arguments Create a “context”. Consider using a Pattern. Method Object Avoid “basic” Types: strings, arrays, integers, etc. Think on objects. Exceptions Operations in real world needing not cohesive collaborators. Sample Code Wrong Right Detection Most linters warn when the arguments list is too large. Tags Primitive Conclusion Relate arguments and group them. Always favor real world mappings. Find in real world how to group the arguments in cohesive objects. If a function gets too many arguments, some of them might be related to the class construction. This is a design smell too. Code Smell 11 — Subclassification for Code Reuse Code reuse is good. But subclassing generates a static coupling. Photo by Brandon Green on Unsplash Problems Coupling Maintainability Solutions Favor composition. Exceptions If hierarchy follows the principle then it is safe. behaves like Sample Code Wrong Right Detection Overriding can issue warnings when subclassing concrete methods.Deep Hierarchies (more than 3 levels) are also a clue of bad subclassing. Tags Composition Conclusion In legacy systems is very common to have and , we need to refactor them and subclass by reasons and not implementative ones. Deep Hierarchies method overriding essential More info Liskov Substitution Code Smell 12 — Null Programmers use Null as different flags. It can hint an absence, an undefined value, en error etc. Multiple semantics lead to coupling and errors. Photo by Kurt Cotoaga on Unsplash Problems Coupling among the callers and the senders. Mismatch among the callers and the senders. If/Switch/Case Polluting. Null is not polymorphic with real objects. Hence Null Pointer Exception Null does not exist on real world. Thus it violates Bijection Principle NULL: The Billion Dollar Mistake Solutions Avoid Null. Use to avoid ifs. NullObject pattern Use . Optionals Exceptions APIs, Databases and external systems where NULL does exist. Sample Code Wrong Right Detection Most linters can show null usages and warn us. Tags Null Conclusion Null is the billion dollar mistake. Yet, most program languages support them and libraries suggest its usage. More info NULL: The Billion Dollar Mistake I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. Tony Hoare 40+ Thought-Provoking Software Engineering Quotes Code Smell 13 — Empty Constructors Incomplete objects cause lots of issues. Photo by Brett Jordan in Pexels Problems Mutability Incomplete objects Concurrency inconsistencies between creation and essence setting. Setters Solutions Pass the object’s essence on creation. Is it Crystal Clear for Everybody That a Date Should Not Mutate? Examples Some persistence frameworks in static typed languages require an empty constructor. Exceptions Stateless objects. Always better solution than static class methods. Sample Code Wrong Right Detection Any linter can warn this (possible) situation. Tags Essence Incomplete Mutable Conclusion Always create complete objects. Make their essence immutable to endure through time. Every object needs its essence to be a valid one since inception. Writing a class without its contract would be similar to producing an engineering component (electrical circuit, VLSI (Very Large Scale Integration) chip, bridge, engine…) without a spec. No professional engineer would even consider the idea. Bertrand Meyer Code Smell 14 — God Objects An object that knows too much or does too much. Photo by Francisco Ghisletti on Unsplash Problems Cohesion Coupling Solutions Split responsibilities. Follow Single Responsibility Principle. Follow . The Boy Scout Rule Examples Libraries Exceptions Facades Sample Code Wrong Right Detection Linters can count methods and warn against a threshold. Tags Cohesive Conclusion Libraries were fine in the 60. In Object Oriented Programming we will distribute responsibilities among many objects. Also Known as Large Class More info Wikipedia Refactoring Guru Coupling: The One and Only Software Designing Problem Code Smell 15 — Missed Preconditions Assertions, Preconditions, Postconditions and invariants are our allies to avoid invalid objects. Avoiding them leads to errors. Photo by Jonathan Chng on Unsplash Problems Consistency Contract breaking Hard to debug Bad cohesion Solutions Create strong preconditions Raise exceptions Fail Fast Defensive Programming Examples Constructors are an excellent first line of defense. lack these rules. Anemic Objects Sample Code Wrong Right Detection It’s difficult to find missing preconditions, as long with assertions and invariants. Tags Consistency Conclusion Always be explicit on object integrity. Turn on production assertions. Even if it brings performance penalties. Data and object corruption is harder to find. Fail fast is a blessing. Fail Fast Philosophy, Explained More info Object-Oriented Software Construction (by Bertrand Meyer) Relations Code Smell 01 — Anemic Models Writing a class without its contract would be similar to producing an engineering component (electrical circuit, VLSI (Very Large Scale Integration) chip, bridge, engine…) without a spec. No professional engineer would even consider the idea. Bertrand Meyer These would certainly not be the last smells. We will keep on smelling the trash trail very soon!

Different

Keep

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

Portfolio

Software Engineer

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

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

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

Too Long; Didn't Read

Companies Mentioned

Maximiliano Contieri

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

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

Too Long; Didn't Read

Companies Mentioned

Maximiliano Contieri

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES