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.
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
- Wrap functions/closures
- 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.
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
- Find a suitable name
- If the helper is a library, break all the services as different methods.
- Methods should always be fulfilled by objects. Static methods are another code smell.
- 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
Solutions
- Avoid kind, isKindOf, instance, getClass(), typeOf, etc..
- Don't use Reflection and Metaprogramming for Domain Objects.
- Replace IFS with polymorphism.
- 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
- Be explicit.
- Work with booleans for boolean conditions. Not integers, not nulls, not strings, not lists. Just booleans.
- 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
- Measure the trade-off of patterns usage.
- Create solutions based on real world names (essential) over architecture (accidental).
- Choose good names.
- 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!