Programming languages, platforms, and ecosystems each carry their own conventions for how identifiers are named. These conventions apply not only to code symbols, but also to file systems, URLs, asset pipelines, APIs, and large content trees.
This reference documents common case and delimiter patterns.
Common Case Styles
snake_case
Words are separated by underscores and written in lowercase.
vacation_pictures
romeo_and_juliet
get_user_id
- Common in file systems, configuration files, and data pipelines.
- Explicit word boundaries that are easy to parse visually and programmatically.
- The underscore increases identifier length compared to PascalCase or camelCase.
kebab-case
Words are separated by hyphens.
vacation-pictures
romeo-and-juliet
get-user-id
- Common in URLs and web-facing identifiers.
- Not valid for many programming language contexts.
- Can introduce ambiguity when hyphens also imply subtraction or flags.
- The hyphen makes the IDs longer than alternatives like PascalCase or camelCase.
camelCase
The first word is lowercase; subsequent words are capitalized.
vacationPictures
romeoAndJuliet
getUserId
- Common in JavaScript variables and functions.
- Word boundaries can blur with acronyms.
- More compact than character-delimited styles like snake_case and kebab-case.
PascalCase
All words are capitalized.
VacationPictures
RomeoAndJuliet
GetUserId
- Common for class names and types.
- Shares the same acronym ambiguity issues as camelCase.
- Commonly used in asset management frameworks like Unreal Engine or content archives.
- More compact than character-delimited styles like snake_case and kebab-case.
SCREAMING_SNAKE_CASE
Uppercase snake case.
VACATION_PICTURES
ROMEO_AND_JULIET
GET_USER_ID
- Typically used for constants.
- Signals immutability or configuration.
- Not typically used for files or content paths.
- The underscore increases identifier length compared to PascalCase or camelCase.
Acronym Ambiguity
camelCase and PascalCase introduce ambiguity when acronyms are involved:
GetId vs GetID
GetJson vs GetJSON
There is no universally agreed convention for handling acronyms in these styles, which often leads to inconsistency within the same codebase.
Single Delimiter Limitations
In large systems, a single delimiter is often not enough to communicate structure and intent. Additional delimiters may be introduced to encode hierarchy directly into identifiers. While this embeds more meaning into names and can create long-term rigidity, it can also dramatically improve organization, sorting, and discoverability. This pattern is most often found in systems that manage large asset collections, such as game engines and content archives. The following examples use snake_case to demonstrate the idea:
dragon_asset__body
dragon_asset__wings
dragon_asset__fire_effect
This approach resolves many sorting and ambiguity issues that arise when all meaning is encoded into a single delimiter. A well-known example of this pattern is BEM, a naming convention designed to manage highly complex CSS rule sets. BEM notably combines kebab-case and snake_case conventions:
primary-header__pre-graphic
site-footer__brand-icon
subscribe-box__upper-text--small
Personal Insights
The following reflects personal preference informed by experience. These are the heuristics I tend to follow when no external standard is imposed:
Decision Tree
- Style guide of the project.
- Style guide of the organization.
- Style guide of the community.
- snake_case when it's ambiguous, or my personal positivity towards snake_case supersedes the community.
Default: snake_case
I do reach for snake_case anytime I can and consider it my default case. I use it on my own file systems and always prefer it for data notation. It feels the easiest for me to read with zero ambiguity when typing it. I believe it is the most universally safe option across operating systems and tools, making it an easy choice for consistency and standardization.
Conclusion
thank_you_for_reading_and_i_hope_you_found_this_helpful.