Are we done on code smells? Probably never!

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 here, Part II here, Part III is here, and Part IV here.

Let's continue...

Code Smell 21 - Anonymous Functions Abusers

Functions, lambdas, closures. So high order, nondeclarative, and hot.

Photo by Roman Mager on Unsplash

Problems

• Maintainability
• Testability
• Code Reuse
• Implementation Hiding
• Debugging

Solutions

1. Wrap functions/closures
2. Reify algorithms in method object / Strategy

Sample Code

Wrong

Right

Detection

Closures and anonymous functions are very useful to model code blocks, promises etc. So It'd difficult to tear them apart.

Tags

• Primitive
• Abuser

Conclusion

Humans read code. Software works ok with anonymous functions but
maintainability is compromised when multiple closures are invoked.

Object-oriented programming increases the value of these metrics by
managing this complexity. The most effective tool available for dealing
with complexity is abstraction. Many types of abstraction can be used,
but encapsulation is the main form of abstraction by which complexity is
managed in object-oriented programming.

Rebecca Wirfs-Brock

Code Smell 22 - Helpers

Do you need help? Who are you gonna call?

Problems

• Readability
• The Least surprise principle
• Bijection Fault
• Static methods

Solutions

1. Find a suitable name
2. If the helper is a library, break all the services as different methods.
3. Methods should always be fulfilled by objects. Static methods are another code smell.
4. Avoid extracting the helpers to Anonymous Functions.

Sample Code

Wrong

Notice static methods.

Right

Or we can make the former Helper stateless for reuse...

Detection

Code naming standards should forbid classes with this name on them.

Tags

• Namings

Conclusion

This is a well established cultural name and a legacy habit from structured programming.

Most developers are reluctant to let old habits go.

We must be aware of the damage this kind of names are bringing us.

Also known as

• Utils

More Info

How to Decouple a Legacy System

Code Smell 23 - Instance Type Checking

Do you check who are you talking to?

Photo by Remy Gieling on Unsplash

Problems

• Coupling
• Meta model interference
• IFs

Solutions

1. Avoid kind, isKindOf, instance, getClass(), typeOf, etc..
2. Don't use Reflection and Metaprogramming for Domain Objects.
3. Replace IFS with polymorphism.
4. Avoid checking for 'undefined'. Use complete objects, avoid nulls and setters, favor immutability and you will never have undefined and ifs.

How to Get Rid of Annoying IFs Forever

Sample Code

Wrong

Right

Detection

Since type checking methods are well known it is very easy to set up a code policy checking the uses.

Tags

• Metaprogramming

Conclusion

Testing for a class type couples the objects with accidental decisions and violates bijection since no such control exists on real world. It is a smell our models are not good enough.

More Info

How to Get Rid of Annoying IFs Forever

Code Smell 24 - Boolean Coercions

Booleans should be just True and False

Problems

• Hiding Errors
• Accidental complexity coupled to one particular language.
• Readability
• Difficulty to hop among languages.
• IFs

Solutions

1. Be explicit.
2. Work with booleans for boolean conditions. Not integers, not nulls, not strings, not lists. Just booleans.
3. Fail fast

Sample Code

Wrong

Right

Detection

This is a language feature. Some strict languages show warnings with this magic wizardry.

Tags

• Coercions
• Primitive

Conclusion

Some languages encourage doing some magic abbreviations and automatic castings. This is a source of errors and a Premature Optimization warning.

We should always be as explicit as possible.

More Info

Fail Fast Philosophy, Explained

It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!

Robert Martin

Code Smell 25 - Pattern Abusers

Patterns are awesome. With great powers comes great responsibility

Photo by Nathan Dumlao on Unsplash

Problems

• Over Design
• Readability

Solutions

1. Measure the trade-off of patterns usage.
2. Create solutions based on real world names (essential) over architecture (accidental).
3. Choose good names.
4. User MAPPER technique to find bijection real entities.

Sample Code

Wrong

Right

Detection

It would be very difficult to create automatic detection rules.

A class name with more than one pattern on it, is a warning.

Tags

• Abuser
• Naming

Conclusion

Chose when to apply a pattern solution. You are not smarter for using too many patterns. You are smart if you choose the right opportunity for everyone.

More Info

Singleton Pattern: The Root of All Evil

How to Decouple a Legacy System

What Exactly Is A Name: Rehab [Part II]

When you have a hammer, every problem looks like a nail.

Will it be the end? Are we done? Guess not!