DEV Community

loading...
Cover image for Code Smell 22 - Helpers

Code Smell 22 - Helpers

mcsee profile image Maxi Contieri Originally published at maximilianocontieri.com Updated on ・1 min read

Do you need help? Who are you gonna call?

Problems

Solutions

  1. Find a suitable name

  2. If the helper is a library, break all the services as different methods.

  3. Methods should always be fulfilled by objects. Static methods are another code smell.

  4. 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

Discussion (4)

pic
Editor guide
Collapse
alainvanhout profile image
Alain Van Hout

You're showing us 'good' code and 'bad' code, but you're not actually explaining why the one is better than the other or what advantages or disadvantages the two alternatives have. In all, it seems that you've simply rewritten two short functions as multiple longer classes.

Collapse
mcsee profile image
Maxi Contieri Author • Edited

hi Alain.

Besides rewrite them (most refactorings are about rewrites) solution is less coupled, has a real world name, is more readable and has no static methods.
Length is not a big issue when declarativeness is a trade off.
For me, its is more intention revealing a formatter that formats than a helper that.... hmm helps?

Collapse
alainvanhout profile image
Alain Van Hout

That does add more detail, thanks. I personally don't see it as less coupled (use a class vs use a function). As to better names, that's a fact but it would work as well if the functions were renames to e.g. formatToFullName and determineCategory (or something better based on the domain). Static or not seems mostly irrelevant to me, since it doesn't really affect transparency (while I would say that the class boilerplate does reduce transparency).

But a class version of the methods of course also works, so to a degree it's a matter of taste I suppose.

Thread Thread
mcsee profile image
Maxi Contieri Author

indeed. it has some taste on it.

According to SOLID principles Class single responsibility is to create instances. Not to be overloaded with static functions. But it is just an opinion.
As long as we don't call them Helpers I think we are in a better position.