Code Smell 22 - Helpers
Subscribe to my newsletter and never miss my upcoming articles
Do you need help? Who are you gonna call?
Problems
Readability
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.
Relations
Also known as
- Utils
More Info
This article is part of the CodeSmell Series.
Hi, just stumbled across this post. A question came to mind after I read this post.
Why not just single functions, instead of creating new instances?
Hi Maxi Contieri, Thanks for the prompt response. However, I am still on the fence. In my current project (React & Redux), we exclusively use (anonymous) functions as they are small and writing unit tests are just a breeze. I just feel like they've been convenient enough.
The code is well maintained from time to time, but no one talked about switching to use Class helpers.
I doubt if it's just a matter of preference or the scope of the projects. Mind if I ask for some more examples for the Problems you mentioned in the Code-smell-21? I'd be very glad to have a better view and understanding.
hi Sy Hung Doan
Some quick questions
How many functions are?
How large is the team?
How do you unit test it?
Do you have good coding names?
Can you embed an example?
Comments (5)