A fundamental principle of object-oriented programming is that a class represents something from outside the code whether a tangible item, like a car, or an abstract concept, like a record. A class should reflect its purpose as a "thing," not an action. Calling a car "drive" would quickly become confusing, and the same is true in your code.
Keeping classes named as nouns maintains clarity and reinforces their role as representations of entities in the system.
What is a noun?
A noun is a word that names a thing. Common examples include tangible items like table, cup, or computer; and abstract entities like record, database, or cloud.
Naming classes as nouns
In your code, class names should clearly reflect what they represent, giving developers an immediate understanding of the class’s role.
Using ProcessOrder
Bad example - This name suggests an action which sounds like it could be a method - but it's meant to represent the order itself
Using Order better represents its role as an entity that holds order-related data and behavior
Good example - A class name that clearly represents a thing is much easier to understand - you couldn't misinterpret this as a method
Later, if you need to perform an action on the order, you might create a ProcessOrder method within theOrderService or OrderProcessor class (see our rule Do you use verbs for method names?)
Events: The exception that proves the rule
In domain-driven design (DDD) and event-driven architectures (EDA), you’ll often see exceptions to this rule. Events like OrderPlaced or UserRegistered are commonly named with verb phrases to represent specific actions or occurrences within the system, rather than entities with persistent state. This naming convention is acceptable, as it indicates a change or trigger rather than a static object. For other class types, however, sticking to nouns keeps the codebase clear and consistent.
Fun fact: Some languages even capitalize nouns in normal writing!. They can just know what's a noun by checking if it's capitalized, but in English we need to remember.
- Do you use clear and meaningful names when coding?
- Do you use verbs for method names?
- Do you avoid generic names like “manager” or "helper"?
- Do you avoid micro-culture jargon and insider terms?
- Are you consistent with the words you use to represent concepts?
- Do you know when to use technical terms versus domain terms?
- Do you avoid using your name or your company’s name in client code?
- Do you use meaningful modifiers for custom implementations?
- Do you follow naming conventions for tests and test projects?
- Do you use clear and meaningful names when coding?
- Do you use verbs for method names?
- Do you avoid generic names like “manager” or "helper"?
- Do you avoid micro-culture jargon and insider terms?
- Are you consistent with the words you use to represent concepts?
- Do you know when to use technical terms versus domain terms?
- Do you avoid using your name or your company’s name in client code?
- Do you use meaningful modifiers for custom implementations?
- Do you follow naming conventions for tests and test projects?