.png){kind=small}
.png){kind=small}
We have returned with the second part of the weekly posts about Bed Smell on our blog. And if you haven't read the first part, just click here. Today, we are going to talk about the Obfuscators family.
Obfuscators is a type of bad smell that masks the behaviour or the purpose of the code, generating poor communication, because it obscures what must be done and the intention, causing confusion to the reader. In this post, we are going to talk about the Obfuscators Vertical Separation and Poor Names. But who are they?
"Variables and functions must be declared where they are used."
This may sound silly, but it helps a lot in code organization and visibility. Remember that we create codes for people, not for machines, and the more readable it is, the faster will be the adaptation of another person who is going to maintain it, or even you when you get back to the code after some time.
Let's see an example!
In the image below, we have a class called VerticalSeparation. When analysing this class, we see that it contains four declared methods and one variable. In the RotateMethodOne method, at the beginning, we have a declaration of a variable, myValue, which will only be used in the last method call (RotateMethodThree). The class shows us that the organization of the methods is a little confusing, we have to scroll to check the contained methods. We have already turned on the alert to implement a refactor in this class.
Let's see what we can improve in the class above?
Taking a look at the class after refactoring, we can see a better visual and physical organization of its content. Within the RotateMethodOne method, we keep the shared routine calls and the cascade calls separated.
As we use the variable declared only in the call of the method RotarMethodThree, which is the last one, we declare it before the method call. This shows that the variable was declared in that piece of code demonstrating the intention to be used just below in the next call. The declaration of the implemented methods also follows the order in which they were called in the main flow.
Other tips for resolving Vertical Separation
Poor Names
One of the most important things in a code is the methods, classes, or variables names. A name must be descriptive and express exactly what it represents in the rule we are working on. Poor Names are totally out of this pattern, that is, they are difficult to understand and without expression.
Let's take an example.
In the class above PoorName, the declaration of properties and method is done completely wrong. Names without expression, use of prefixes, declarations with invalid standards. We have a method that by name we have no idea what it does. This class urgently needs a refactor.
In the class after refactoring, we have the properties declared with the Conventions used in C#. And now with a more extensive name, the method and its internal declarations express exactly what it does.
Other tips for solving Poor Names:
I hope you enjoyed this content! Next post, we will talk about the Bad Smells of the Dispensables Family.
May the force be with you!
