naming -Manager, -Helper, -Factory is not good? My...
# codereview
c
naming -Manager, -Helper, -Factory is not good? My coworker said don't use it. And I don't understand because google also uses those names. And personally, I think those names are fine.
l
I dislike most of them. Everything is a Manager or Helper, these words usually don't add much information to the class, but take a lot of namespace
k
"Manager" is too broad a term and can hint that such a class is violating the Single Responsibility Principle. Try instead to describe exactly what the class does: if it does too many things, it might be an indication that you should split it.
e
#naming
u
Try to find more idiomatic names for the stuff you are modeling, if you cant, only then fallback to those
t
There was a time in my career where a wise mentor encouraged me to steer away from object types that ended in "er". He had observed that when people used these names, it was often a code smell and the underlying object had been put together to "do" a thing. And that it was better to strive for names that better described what the thing was. Subtle at times. And there are words in the english language that end in er, but have become synonymous with related nouns. In Kotlin, which is a "multi paradigm" language, I'm not sure this advice applies though. That advice came in the context of the world of Smalltalk, where it was turtles^H^H^H^Hobjects all the way down. I still find though, that I tend to steer clear (but not asbolutely avoid) "er" objects.
c
@Travis Griggs what is
^H^H^H^H
?
k
@chanjungskim https://en.wikipedia.org/wiki/Backspace#^H - see especially the sentence about epanorthosis.
today i learned 1