Naming conventions: Client, Driver, Actor, Adapter, Broker, Manager, EventEmitter, PubSub, EventBus

Viewed 48

I have a mild case of analysis paralysis when it comes to naming.

Suppose we are wrapping some google API. These all seem reasonable:

googleClient
googleDriver
googleActor
googleAdapter
googleBroker

Actor might be more suited to a more concurrent program. But then google API is inherently asynchronous so maybe a good fit.

Suppose the API supports websockets or push messages and it supports methods like .subscribeToEventA(... it might make sense to call it

googleEmitter
googlePubSub
googleEventBus

or even

googleWrapper

The issue being they all seem reasonable and I have no rule of thumb for choosing between them. Is there a general style guide to lean on or a rule of thumb? Maybe some authoritative glossary for terms like these?

1 Answers

Naming things is subjective and so there is no right or wrong answer to what something should be named.

However you can name things based on well established design patterns so readers are more likely to be knowledgeable as to why something is named as it is.

Also key to naming things is to try to be consistent. Once you have settled on a name for a type of entity it's a good idea to add it to a Domain Specific Language (DSL). Having a documented vocabulary for your domain then makes it easier for other authors to use consistent naming conventions in your environment.

Related