Let assume that we have a system in which the users can chat with each other and we are working on the backend.

We can name the service which fetches the chats in one of the following ways:


If we use the second version, is it a bad practice or it is ok in your opinion ? The idea is that such an approach is repeated anywhere, also in variable names.

The variable holding that service will be named userChatsService and so on. Another variable may be called userPhotosService etc, instead of just photosService.

Also the folder structure follows such conventions, such as Services/Users/UsersChatService

This way of over specifying the variable names is done with the intent to allow the system to be extended later, even if there is no information about this extension now. (Ex: a chat system between merchants might be coming later).

Is this way of thinking a premature optimization, or too much optimistic thinking, or is it a good practice ?

  • Is the variable held inside some sort of "User" object? If so, the "user..." prefix is probably overkill. If not in a User object, would it make sense to change? – user949300 Nov 1 '18 at 21:44
  • It's not premature optimization, it's YAGNI. If you ever have a pressing need to make these kinds of naming changes, there are adequate tools available in most IDE's to do exactly that. – Robert Harvey Nov 1 '18 at 21:47
  • The variable may be held for example inside a UserChatsController. Also here the question is, is appending User to the ChatsController name necessary ? Do you prefer being so specific, or is just overkill having such long names for our classes/variables – Kristi Jorgji Nov 1 '18 at 21:47
  • 1
    You might also want to read about the smurf naming convention (blog.codinghorror.com/new-programming-jargon, #21) - something to beware of at the extreme end. – Aganju Nov 1 '18 at 22:23
  • 2
    On a side note, some of the best OOP advice I ever read is that whenever you have a FooManager or FooEntity or FooController or FooWhatchamamadinky, consider if it makes sense to rename it to a simple "Foo" or "Foos". Though this goes against some current "best practices". – user949300 Nov 1 '18 at 22:49

In a system where you have only one service of that kind, ChatsService is obviously clear enough. If you will later get a user chatting service and a merchant chatting service, rename the classes accordingly to make a clear distiction. Ideally, your environment provides support for automatic renaming, which makes this easy.

Of course, sometimes renaming classes afterwards is not that simple, because they become part of a fixed API of a reusable lib or database schema. In that case, you better try to plan ahead as best as possible if you will really expect to get a UserChatsService and a MerchantChatsService.

  • Thank you for the answer. You got exactly the point. In this scenario, the particular engineer is trying to prepare for a uncertain near future (uncertain because as of that moment, no one told him that this new particular merchant chat may even be an idea). I have noticed such thinking in some of my devs and I am confused also myself on whether to consider it as good or bad. Obviously, the thought to let clear code and try to plan is great, but doing so without having a concrete reason is confusing. – Kristi Jorgji Nov 1 '18 at 22:09
  • 1
    Depending on language, you may be able to generify this. Instead of UserChatsService, consider ChatsService<UserChat>. This is a nice compromise between predicting the complete future at 20/20, and putting your head in the sand. – user949300 Nov 1 '18 at 22:42

I'm going to approach this in a slightly different way: It doesn't matter.

The key takeaway from this question should not be about how we name things. Instead we need to focus on the cost incurred when things need to be renamed, because, as many have pointed out already, future-proofing an application is waste of time. Remember, the quality of an application's design is best-understood through evaluation of how difficult it is to make changes as business rules evolve and processes develop.

With the above in mind, we can see this is really a question about business value. Is there business value generated by spending time trying to standardize a particular naming convention? Potentially. As long as we keep the focus on the things that matter. That is, the public surface of your application (types, interfaces, methods).

For example, mandating that a developer name a variable holding a UserChatService object userChatService does not add business value, because a dependency cannot be created on a variable name. In fact, such a rule would make refactoring UserChatSerice to ChatService even more painful because locally scoped variables would need to be renamed.

So the next question is how much business value is generated by having strict naming conventions for your application's public surface? These days, IDE's make refactoring a pretty painless process, so unless there are ancillary effects that arise from refactoring a class name (deployment, distribution, etc.), I'm not so sure much value is really added by such a convention.

The most value is added through conventions regarding the published surface of your application. Conveniently, conventions already exist (e.g. REST). Focus on that.


There are only two hard things in Computer Science: cache invalidation and naming things Phil Karlton

The amount of design capital you invest in a name depends on its visibility. It's fairly common that the implementation language will give you a great deal of freedom in selecting a name, and choosing a suitable spelling is a matter of convention. Private things don't require much investment, because the cost of change is small. Published names, on the other hand, are expensive to change.

Kevlin Henney has at least one talk focusing on names (slides)

UserChatsService is bad practice, because the use of the world "User" indicates that you haven't really invested much thinking into the use case (we expect a human being to be involved in the chat somewhere, and can't be bothered to narrow it down beyond 7 billion people).

It's fairly common to separate the name for the role from the name for an implementation - think List vs ArrayList or LinkedList.

Is this way of thinking a premature optimization

Prediction is hard, especially about the future; it's probably better to focus on a good name for the thing you have now than it is to focus on a name for a thing you may not have later.

That said, following local custom has its own merits, even when the local custom is not optimal.

  • 1
    I've also heard the Karlton quite as "There are only two hard things in Computer Science: cache invalidation, off by one errors, and naming things". :-) – user949300 Nov 2 '18 at 5:41
  • 2
    @user949300: You might be thinking of this. – Greg Burghardt Nov 2 '18 at 12:10

Always consider context. If the higher level already defined the context (like "this is about a user"), you typically do not repeat it on the lower level. High-low could be program-class, class-member or method-argument.

Example: class TextMessageLogger may have a method Log(string message). This would be fine and clear, you would not write LogTextMessage(string textMessage), it would be noisy and needlessly verbose within context.


If you or your team find the need to keep renaming your class afterwards, then you might consider changing the way you name classes. If you don't, and your team doesn't, then it's fine. That's my whole kind of pragmatic take on this.

Generalizing a name tends to reduce the temptation to rename it at some cost to the clarity of how it works and/or possibly some clarity in how to use the interface (worse). Controls tends to have fewer temptations to change as a name than ControlMap. At the same time Controls might be less descriptive of how the interface is supposed to be used.

At the same time if your names are lacking in specificity, then you might encounter a temptation to rename to disambiguate the name from a new one you want to introduce. It's all a balancing act: wax on, wax off, that sort of thing. I wish balance could be taught in some perfect way but sometimes you just have to stand on a boat in the middle of a lake and do karate moves without falling, and if you fall, then ideally you learn from your mistake.

enter image description here

Balance is something you have to learn on your own and it's something that's going to vary a bit from one individual to the next because all of our life experiences are different. It's like how love feels and unicorn energy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.