Naming Conventions and Case Styles — camelCase, snake_case, kebab-case, PascalCase

A naming convention (case style) is the rule for how you mark word boundaries in a name made up of multiple words. userName, UserName, user_name, and user-name all mean the same thing, yet they look different and are used in different places. This article lays out, accurately, the definition and an example of each of camelCase / PascalCase / snake_case / SCREAMING_SNAKE_CASE / kebab-case / dot.case, the conventions per language and context, how to think about word boundaries when converting, lint tools for keeping things consistent, and common mistakes.

1. Why naming conventions matter

Naming conventions are not just a matter of taste. In code written by a team, the more uniform the naming, the easier it is to read and the fewer mistakes occur. For example, if userName and user_name are mixed in the same file, the reader hesitates for a moment, wondering "is this a different variable?"

• Readability: word boundaries are clear at a glance, so you can grasp a name's meaning quickly.
• Consistency: when things of the same kind are written in the same style, search, replace, and autocompletion work more smoothly.
• Effect on behavior: in CSS classes, URLs, JSON keys, and more, a difference in case is treated as a different thing entirely (in most environments, case is significant). It is not merely a cosmetic issue.
• Language conventions: each language has a "standard style," and following it makes your code blend naturally with external libraries and your team's existing code.

In short, naming conventions concern both readability for humans and correctness for machines. First, let us nail down the exact form of each case.

2. Definition and example of each case

Here are the main case styles, compared using the same words (the three words "user profile id").

• camelCase gets its name from the way the interior capital letters rise up like a camel's humps.
• PascalCase is camelCase with the first letter also capitalized, and it is also called UpperCamelCase.
• SCREAMING_SNAKE_CASE is snake_case in all uppercase; it is often used for constants and is also called CONSTANT_CASE.
• kebab-case is named after skewered kebab pieces and refers to the hyphen-joined style.

Hyphens and underscores look similar, but they can be used in different places. In many programming languages, a hyphen cannot be distinguished from the subtraction operator, so it cannot be used in identifiers. For that reason, kebab-case is used not for variable names in code but mainly in CSS, URLs, and file names.

3. Conventions per language and context

Even for the same "variable name," the standard case differs by language. Here are the representative conventions.

* C# has finer distinctions, such as PascalCase for methods and camelCase for local variables. ** Conventions vary by team and official guide; C#, for instance, recommends PascalCase for constants. When in doubt, it is safest to follow the language's official style guide (PEP 8 for Python, Effective Go for Go, and so on).

Outside of code, there are also standards per context.

• CSS class names: kebab-case is common (e.g., .main-nav). Naming methodologies like BEM combine underscores and hyphens to express structure.
• URL paths / file names: kebab-case is the standard (e.g., /blog/naming-conventions-case-styles/). Sticking to lowercase prevents mistakes caused by mixing up case.
• Constants: regardless of language, SCREAMING_SNAKE_CASE is widely used (e.g., MAX_RETRY_COUNT).
• Environment variables: following shell conventions, SCREAMING_SNAKE_CASE is standard (e.g., DATABASE_URL, API_KEY). In POSIX shells, uppercase plus underscores is traditional, and hyphens cannot be used.
• JSON keys: depending on the API, both camelCase and snake_case are possible. The important thing is not to mix them within a single API.

4. How to think about word boundaries when converting

When you convert from one case to another (with a tool or a function), the crux is correctly deciding "where the word boundaries are." Once you fix how you perceive the boundaries, all that remains is to apply the separator and the casing.

• snake_case / kebab-case have explicit boundaries. The positions of _ or - are the word boundaries as is.
• camelCase / PascalCase have implicit boundaries; the basic rule is to treat the transition from lowercase to uppercase as a boundary. For userProfile, it splits into user and profile.

The tricky part is handling consecutive uppercase letters (acronyms). In names like parseHTML or HTTPServer, where to split depends on the style.

In other words, the essence of conversion is to "break a name into a sequence of words and reassemble it in the target case." As long as you read the original case correctly, converting among camelCase ⇄ snake_case ⇄ kebab-case can be done mechanically.

5. Consistency and lint tools

Naming conventions are harder to "keep" than to decide. Relying on manual review alone leaves gaps, so the standard practice is to introduce a lint tool that checks automatically.

• ESLint (JavaScript / TypeScript): with the camelcase rule or @typescript-eslint/naming-convention, you can enforce conventions such as camelCase for variables and PascalCase for types.
• Pylint / flake8 (pep8-naming) (Python): inspects naming in line with PEP 8 (snake_case for functions, PascalCase for classes, and so on).
• gofmt / golint, clippy (Go / Rust): format and warn according to each language's standard style.
• EditorConfig and CI: built into format-on-save or automatic checks on pull requests, they reject convention violations before merge.

The key is to not merely write the convention in prose but to enforce it mechanically with tooling. That way, even when new members join, you keep consistency without having to point it out in review every time.

6. Common mistakes

Finally, here are the typical stumbling blocks around naming conventions.

• Ignoring the language's conventions: writing userName in Python out of JavaScript habit, for instance. It makes the reader speculate needlessly, "did they port this from another language?"
• Mixing cases within a single project: when user_id and userId coexist in the same codebase, searchability drops and it becomes a breeding ground for bugs.
• Underestimating case sensitivity: URLs, file names, and JSON keys are often case-sensitive, so UserId and userid are treated as different things. In particular, developing on a case-insensitive file system and deploying to a case-sensitive server tends to cause breakage.
• Using hyphens in identifiers: in many languages, user-name is interpreted as "user minus name" and cannot be used as a variable name. In code, use snake_case or camelCase.
• Inconsistent acronym casing: when userID, userId, and userid are mixed, consistency falls apart. It is safest to settle on one for the project and lock it in with a linter.

Every one of these mistakes has the same root, and you can avoid them by being thorough about "matching conventions and staying consistent." When in doubt, follow the standard for your language and context, and enforce it with tooling.