Code Smell 22 - Helpers
Do you need help? Who are you gonna call?
Least surprise principle
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.
Notice static methods.
or we can make the former Helper stateless for reuse...
- Code naming standards should forbid classes with this name on them.
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
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.