Not long ago, I shared the importance of developing a style guide for game development projects regardless of the size of the project. A style guide is more than just a set of rules; it’s the backbone of consistency across a project. One of the most fundamental elements it defines is the naming scheme.
Naming Importance
At first glance, naming might feel like a small detail compared to gameplay mechanics or visual style. But when you’re dealing with thousands of assets, files, and scripts, inconsistent or unclear names can quickly snowball into wasted time, broken references, and team miscommunication. That’s why defining a solid naming scheme early and documenting it in your style guide is essential.
Consistency in naming prevents confusion, reduces errors, and makes it much easier for team members to navigate the project. For example, it’s essential to avoid spaces in any folder or file names, since many systems can’t properly process paths that contain them. Instead, a clear and explicit naming convention ensures that there’s no ambiguity about what an item refers to. At the same time, names should balance clarity with practicality—file names that are too long can quickly cause problems, especially on Windows, which enforces file path length limits.
Example Naming Conventions
There are several established approaches to naming, and the best choice often depends on your team’s preferences and the type of project you’re working on. Common conventions include:
- PascalCase – The first letter of each compound word is capitalized (e.g.,
PlayerController). - camelCase – The first word is lowercase, with subsequent words capitalized (e.g.,
playerSpeed). - kebab-case – Words are separated by hyphens, typically in lowercase (e.g.,
street-lamp). - snake_case – Words are separated by underscores, typically in lowercase (e.g.,
level_01). - UPPER_SNAKE_CASE – All letters are capitalized, with underscores separating words (e.g.,
PLAYER_MAX_HEALTH).
Each convention has its advantages, and many teams use a mix depending on context, PascalCase for classes, snake_case for file names, or UPPER_SNAKE_CASE for constants, for example. The key is consistency: once a scheme is chosen, it should be applied universally.
Inclusive Word Choice
Naming conventions aren’t only about structure and clarity; they’re also about the message those names send. Words carry weight, and the language we use in our projects can unintentionally reinforce outdated or harmful terms. By choosing inclusive alternatives, teams not only communicate more effectively but also create an environment that is respectful, professional, and welcoming for everyone.
The following provides guidance and suggestions to help you choose words and names that are respectful and appropriate for all situations and audiences:
| Word Name | Alternative Word Name |
|---|---|
| Blacklist | deny list, block list, exclude list, avoid list, unapproved list, forbidden list, permission list |
| Whitelist | allow list, include list, trust list, safe list, prefer list, approved list, permission list |
| Master | primary, source, controller, template, reference, main, leader, original, base |
| Slave | secondary, replica, agent, follower, worker, cluster node, locked, linked, synchronized |
Naming schemes may seem like a small detail, but they’re one of the building blocks of a maintainable, professional project. They reduce friction, help new team members get onboarded faster, and minimize the chance of costly mistakes.
In upcoming posts, I’ll dig deeper into how naming schemes apply to different areas of a project, such as class naming versus asset naming, and why treating them differently makes sense.