A clear, consistent naming scheme not only improves readability but also makes collaboration easier. When it comes to naming object-orientated classes, following a proper convention helps developers quickly understand what a class represents and how it’s meant to be used.
In C# class names follow PascalCase and should typically be written as nouns, since a class usually represents an object, concept, or entity in your system. Depending on the type of class, a suffix may also be added to clarify its role. These suffixes often correspond to design pattern categories, such as Creational, Structural, or Behavioral, which provide a shared vocabulary for organizing code.
By combining consistent casing, noun-based naming, and meaningful suffixes tied to pattern types, your class names become self-explanatory. This reduces guesswork, speeds up onboarding for new developers, and enforces a style that keeps your project clean and maintainable over time.
Below, is a break down of some common class naming schemes for each major pattern category and highlight typical suffixes or naming practices that make a class’s purpose clear at a glance.
Creational Patterns
Creational patterns deal with object creation. Classes in this category define how objects are instantiated, often abstracting away complex creation logic. They help ensure that objects are created in a controlled, flexible, and reusable way.
| Type | Prefix | Suffix | Example Name | Notes |
|---|---|---|---|---|
| Factory | – | Factory | EnemyFactory | Responsible for creating instance of a general type of object based on logic, without specifying exact details of each object. |
| Object Pool | – | Pool | EnemyPool | Manages a pool of reusable objects to optimize performance and resource usage. |
| Prototype | – | Prototype | EnemyPrototype | Creates new objects by copying existing ones, useful for generating similar objects efficiently. |
| Spawner | – | Spawner | EnemySpawner | Manages the creation and placement of objects, often used to control dynamic object generation in games. |
| Singleton | S | – | SDatabaseConnection | Implements the Singleton design pattern, ensuring only one instance of the class exists. |
Structural Patterns
Structural patterns focus on how classes and objects are organized and how they relate to one another. Classes in this category define relationships, hierarchies, or compositions to make the system more modular and maintainable.
| Type | Prefix | Suffix | Example Name | Notes |
|---|---|---|---|---|
| Component | – | Component | HealthComponent | Represents a part or module that can be attached to game objects. |
| Decorator | – | Decorator | PlayerDecorator | Enhances or adds functionality to existing classes or components. |
| Flyweight | – | Flyweight | BulletFlyweight | Reduces memory usage by sharing common data among similar objects, useful for managing large numbers of similar objects efficiently. |
| Service | – | Service | AudioService | Provides specific services or utilities, often to decouple functionality. |
| UI Element | UI | – | UIInventory, UIStartButton | Used for classes that manage UI elements. |
Behavioral Patterns
Behavioral patterns define how objects interact and communicate with each other, focusing on algorithms, workflows, and responsibilities. Classes in this category often encapsulate actions or strategies that can vary independently from the objects that use them.
| Type | Prefix | Suffix | Example Name | Notes |
|---|---|---|---|---|
| General | – | – | Tree, Lamp, Box | Basic MonoBehaviour classes used for simple, one-off game objects. These typically have no specific prefix or suffix. |
| Abstract Class | – | Base | CharacterBase | Used for abstract or foundational classes that are not instantiated directly but serve as base classes for inheritance. |
| Behaviour | – | Behaviour | AIBehaviour | Defines specific behaviors or actions in the context of game objects. |
| Command | – | Command | MoveCommand | Encapsulates actions as objects, making it easy to manage, undo, or repeat them. Useful for things like undo functionality and command history. |
| Controller | – | Controller | PlayerController | Manages input and interaction logic for game objects. |
| Event | – | Event | GameEvent | Represents events that can be triggered and handled in an event-driven system. |
| Interface | I | – | IDamageable | Defines a contract for classes; the I prefix is sometimes used to denote interfaces. |
| Manager | – | Manager | GameManager | Manages game-wide logic or specific aspects of the game, like audio or input. They are often singletons but not always. |
| Observer | – | Observer | ScoreObserver | Notifies subscribed objects when a change occurs. Useful for event-driven systems where multiple components need to react to changes. |
| ScriptableObject | – | Data | PlayerData | Used to create assets that hold data; the Data suffix indicates that the object is used for storing data. |
| State | – | State | PlayerState | Represents a particular state or condition within a state machine. |
| Strategy | – | Strategy | MovementStrategy or IMovementStrategy | Represents a strategy or algorithm used by a class or component. Strategy classes are typically Interfaces. |
| System | – | System | CombatSystem | Represents large-scale systems that manage complex logic or workflows. |
| Utility/Helper | – | Utility, Helper | MathUtility, StringHelper | Provides utility functions or methods, often static and used across various parts of the code. |
These examples represent just a small selection of common class naming conventions tied to design pattern categories, but they provide a solid starting point. By following these basic guidelines, using PascalCase, nouns, and meaningful prefixes/suffixes, you can create class names that clearly communicate purpose, improve readability, and make your codebase easier to navigate. As you gain experience, you can expand and adapt these conventions to suit the specific needs of your projects and team.