11 code smells to avoid in your code
Foto de Дмитрий Хрусталев-Григорьев en Unsplash
1 - Comments in the code
Avoid comments that try to explain what the code does. The code has to be readable without comments that explain what it does.
2 - Too many arguments
Functions that have more than 3 arguments are difficult to test and it’s quite possible that they do more than one thing. You should strive for having at most 3 arguments.
3 - Dead function
Function that nobody calls. Modern IDE’S can help you on this because this methods appear in grey colour. Get rid of this dead functions. The less code that you have, the better.
4 - Duplication
Don’t repeat yourself (DRY) it’s one of the most important concepts. Duplicated code it’s a missed opportunity to abstract functionalities.
5 - Code at wrong level of abstraction
In the following block of code the function percentFull
is at the wrong level of abstraction as there are implementations of an Stack
that could not know how full they are.
public interface Stack {
Object pop() throws EmptyException;
void push(Object o) throws FullException;
double percentFull();
}
It would be better placed in a derivative interface such as BoundedStack
.
6 - Feature envy
This principle it’s related with the principle of having “shy code”. If you are doing e.getTenthRate().getPennies()
it’s not good cause you are accessing methods that are from an object returned by getEngine() method.
public class HourlyPayCalculator {
public calculateWeeklyPay(HourlyEmployee e)
int tenthRate = e.getTenthRate().getPennies()
}
7 - Replace magic numbers with constants
The code should not have hardcoded values, instead of that is better to use constants that abstract the reader of the code of that particular value that don’t provide value.
8 - Function names should say what they do
Seems obvious this principle but if the name of the method doesn’t explain what is doing it’s that the method is doing more than one thing and then it’s difficult to give a name or that the code writer has not choosen a good name for that method.
9 - Prefer polymorphism to if/else or switch case
Have you seen code that has 10 different if/else branches. This is a bad sympthon that the code is not well written and there’s a good opportunity to use polymorphism. Instead of asking the type of the object and call a function doing a cast it’s better to call a method of an object and depending of his type it will execute the definition of the method.
10 - Encapsulate conditionals
You don’t need to know the details of a conditional that calls more than one function. It’s better to group those calls into a method to abstract the reader of the details of the conditional and only provide a method function call.
11 - Avoid negative conditionals
Negative conditionals read really bad, it’s easier to read a conditional with isActive() than another one with isNotActive()
Conclusion
In this post we have seen 11 code smells that you have to avoid in your code if you want to increase the quality of it.
Comments