I am reading the book Clean Code http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
The author mentions that you should avoid words like Manager, Processor, Data or Info in the name of the class. I have used these everywhere. What are some better names? I have a class that is responsible for starting and stopping connections. So I named it ConnectionManager.
OH, NO !!
Please don't be intimidated by general pronouncements about how you "should" name things. They are your things, after all. Maybe your name "Manager" is better than "Connection Manager" because it's shorter. Especially so if that section of your code mainly manages "connections" and little else.
I believe that such books have very useful ideas, but only for coders who will never read them. Why? Because engineers who do read such books have already internalized and incorporated the soundest of the principles in them. And coders who won't read them don't care.
My guess is the book makes this point because it's trying to encourage you to choose a more descriptive name for your class. There's no "naming convention" to follow here; that's the problem you fell into in the first place. Any universal naming convention won't be able to consider the specific class and choose the best name for it. Expressivity is more important than following a naming convention. Calling a class a "Manager" or a "Processor" doesn't say very much about it and what it does to a person who is reading your code for the first time.
If you really can't think of anything better, there's nothing inherently wrong with naming a class
ConnectionManager
. But I'd at least name it after the type of collections that it manages. Or maybe how it manages those collections. Or why it manages those collections.Also consider that following "one-size-fits-all" rules rarely helped anyone to write better code (at least, not better in the sense of "more understandable" or "more expressive). I tend to postfix the names of all my native wrapper classes with
Manager
. For example, I might have classes calledDwmManager
, orVisualStylesManager
. In that very specific case, it does mean something to me. If I see a class namedManager
in my code base, I know it wraps a bunch of closely-related functionality. You have to make the decision on a case-by-case basis, understanding what you're ultimately trying to accomplish.If you read Code Complete and missed the part about writing code that's clear and understandable (and therefore maintainable), you might have missed the point.