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

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 here and Part II 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

1. Find cohesive relations among arguments
2. Create a “context”.
3. Consider using a Method Object Pattern.
4. Avoid “basic” Types: strings, arrays, integers, etc.
5. 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

1. Favor composition.

Exceptions

• If hierarchy follows the principle behaves like then it is safe.

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 Deep Hierarchies and method overriding, we need to refactor them and subclass by essential reasons and not implementative ones.

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

1. Avoid Null.
2. Use NullObject pattern to avoid ifs.
3. 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

1. Pass the object’s essence on creation.
2. 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

1. Split responsibilities.
2. Follow Single Responsibility Principle.
3. 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

1. Create strong preconditions
2. Raise exceptions
3. Fail Fast
4. Defensive Programming

Examples

Constructors are an excellent first line of defense.

Anemic Objects lack these rules.

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!