Give Types Meaningful Names

Have ever wondered why classes called Manager, Helper or Service are often huge? Like a CustomerManager class with more than 50 public methods and nearly 10,000 lines of code!

When we need to modify such sizable classes, it can be a daunting task. For example, other developers could be making changes to CustomerManager at the same time as us. We don’t want to step on their work—and we don’t want them to step on ours. 

How do we know the new functionality we want to put into CustomerManager does not already exist? Time to trawl through the code and check. We could have used that time more productively, but this is the reality of working with large classes.

What about a class called PasswordHelper? What might we find in here? Maybe we discover 

• methods using different password hashing algorithms, 
• validation to compare hashed passwords to stored hashes, and
• code to retrieve password hashes from the database.

PasswordHelper‘s responsibilities are already quite broad. As PasswordHelper attracts more password-related system behaviour, some developers might mistake the class as a dumping ground for related concepts, like token-based authentication or code to connect to an authentication service, like Auth0. 

And that’s a problem. PasswordHelper‘s ambiguous name has led to the grouping of only vaguely-related responsibilities.

Classes called Helper or Manager tend to confuse developers. Their names are not meaningful. If I have customer-related code and I am stuck for a place to put it, why not put it in CustomerManager? That sounds like the right place to put it. 

Class CustomerManager, and classes like it, have low cohesion.

Cohesion means putting things together that belong together and change for the same reason. 

It’s a failure of us developers to come up with meaningful names. Years ago, when I didn’t know right away what to call a new authentication type, say, I named it AuthenticationHelper or AuthenticationManager. Innocently enough, at that moment and without realising it, I had compromised the codebase potentially for years to come.

A more beneficial approach might be to take out 5-10 minutes of our busy day to come up with a beautiful name for our new class – a meaningful, cohesion-indicating name. 

OK, some meaningful type name examples are in order:

• PasswordHasher, or for a specific hash algorithm, Sha1PasswordHasher,
• Authenticator, or if there are different versions, maybe this could be OAuth2Authenticator,
• CustomerRepository, possibly for customer data retrieval, or even perhaps CustomerGetter? 

These are merely some ideas. It’s up to you—the most meaningful name depends on your scenario.

We never intend to cause damage to our codebase, but that is what we are doing when we give our types ambiguous, meaningless names. And over time such classes tend to grow into difficult-to-manage God-classes. 

Please think carefully about the names you give to your types. Spend time coming up with a specific, unambiguous and meaningful name.