Text Case Conventions Every Developer Should Know

Naming things is one of the hardest problems in computer science — and case conventions are where it gets messy. Should your API endpoint be /user-profile or /userProfile? Should your database column be created_at or createdAt? Should your React component be UserProfile or userProfile?

Getting case conventions right makes your codebase readable, consistent, and professional. Getting them wrong creates friction for every developer who touches your project. This article is a definitive reference for when to use each convention, with real-world examples from major codebases and practical enforcement strategies.

The Five Main Case Conventions

1. camelCase

Pattern: first word lowercase, subsequent words capitalised, no separators.

Examples: userProfile, isActive, getUserById

Used for: JavaScript variables and functions, Java variables and methods, JSON keys (de facto standard).

Why: Compact, readable, and the dominant convention in JavaScript and Java ecosystems.

2. PascalCase (UpperCamelCase)

Pattern: Every word capitalised, no separators.

Examples: UserProfile, HttpRequest, DatabaseConnection

Used for: Classes, types, interfaces, React components, C# identifiers, .NET.

Why: Distinguishes types from instances/values at a glance. A UserProfile is a class; a userProfile is an instance.

3. snake_case

Pattern: All lowercase, words separated by underscores.

Examples: user_profile, is_active, get_user_by_id

Used for: Python variables and functions, Ruby, PHP, database columns, environment variables, file names in Unix systems.

Why: Highly readable, unambiguous, and the PEP 8 standard for Python. Underscores are also URL-safe and shell-friendly.

4. kebab-case (dash-case, lisp-case)

Pattern: All lowercase, words separated by hyphens.

Examples: user-profile, is-active, get-user-by-id

Used for: URL slugs, CSS class names, HTML attributes, command-line flags, file names.

Why: Hyphens are the standard word separator in URLs and CSS. They improve readability in prose-like contexts and are unambiguous in URLs (unlike underscores, which can be hidden by underlines in links).

5. UPPER_SNAKE_CASE (SCREAMING_SNAKE_CASE)

Pattern: All uppercase, words separated by underscores.

Examples: MAX_RETRIES, API_KEY, DATABASE_URL

Used for: Constants, environment variables, configuration keys, enum values in some languages.

Why: Visually distinct from variables. Signals "this value is fixed and should not change."

Convention Cheat Sheet by Context

Case Conversion in the Wild: Lessons from Major Codebases

The world's most influential open-source projects enforce case conventions rigorously. Studying their patterns reveals why consistency matters at scale:

React (Facebook/Meta)

React's codebase is a masterclass in convention discipline. Components use PascalCase (UserProfile.js), hooks use camelCase (useState, useEffect), and internal utilities use camelCase with descriptive names. The ESLint config in create-react-app enforces these conventions automatically. When Facebook migrated to TypeScript, they preserved these patterns because the cognitive cost of renaming thousands of identifiers outweighed any marginal improvement.

Python Standard Library

The Python standard library follows PEP 8 with military precision. Functions and variables use snake_case (json.load, urllib.request). Class names use CapWords (PascalCase equivalent: HttpResponse, BaseException). Constants use UPPER_SNAKE_CASE (MAX_LINE_LENGTH, DEFAULT_TIMEOUT). The consistency is so universal that Python code from 1994 and Python code from 2024 look structurally identical in naming.

The Linux Kernel

The Linux kernel uses snake_case almost exclusively, with a twist: type definitions (structs, enums) often use suffixes rather than prefixes for disambiguation. Function names are descriptive and lowercase (vfs_read, kmem_cache_alloc). Global variables use prefixes to avoid namespace collisions. The kernel's CodingStyle document explicitly forbids camelCase and Hungarian notation, making it one of the few major projects that has successfully resisted Java-influenced naming.

Case Conversion Across Programming Languages

When building APIs or polyglot systems, you inevitably translate between conventions. Here is how the major languages map:

How to Enforce Conventions in Your Codebase

Manual enforcement fails at scale. Modern development tools can check and auto-fix naming conventions before code reaches review:

ESLint (JavaScript/TypeScript)

The @typescript-eslint/naming-convention rule allows granular control. You can require camelCase for variables, PascalCase for classes, UPPER_SNAKE_CASE for constants, and kebab-case for filenames. When combined with Prettier and Husky pre-commit hooks, violations are caught before they reach your repository.

Pylint and Black (Python)

Pylint's invalid-name checker flags variables that violate PEP 8 conventions. Black, the Python formatter, does not enforce naming but ensures consistent spacing around operators and line breaks. Together, they create a Python codebase where the only naming decisions are semantic, not stylistic.

RuboCop (Ruby)

RuboCop's Naming department includes cops for variable name length, method name format, and constant naming. The autocorrect feature can rename identifiers in bulk when you decide to change conventions mid-project — though this should be done cautiously to preserve git blame history.

Pre-Commit Hooks

The most effective enforcement strategy is a pre-commit hook that runs your linter on changed files only. Tools like lint-staged integrate with Husky to ensure no convention violations enter your main branch. This shifts the burden from code reviewers to the developer's own machine, where fixes are faster and less embarrassing.

Special Cases and Edge Cases

Acronyms in Names

Debate rages over whether "HTTP" should be "Http" in camelCase or "HTTP" in PascalCase. Google's style guides recommend treating acronyms like words: XmlHttpRequest, not XMLHTTPRequest. This avoids ALLCAPS visual noise.

Numbers in Names

Always separate numbers with an underscore or hyphen: user_1 or user-1, not user1. The latter is harder to read and can be ambiguous (is "user1" one word or user + 1?).

Non-English Words

If your codebase includes non-English terms, romanise them consistently. Do not mix scripts — it breaks searchability and tooling.

Emoji and Unicode in Identifiers

Modern JavaScript allows emoji in variable names, but doing so creates tooling nightmares. Most linters, text editors, and code review systems struggle with non-ASCII identifiers. Stick to basic Latin characters for maximum compatibility. If you must include special characters, use Unicode escapes in comments or documentation, never in identifiers.

URL Encoding and Case Sensitivity

URL paths are case-sensitive on most Unix-based servers but case-insensitive on Windows IIS. A kebab-case URL (/user-profile) avoids ambiguity because it contains no uppercase letters. When designing APIs, assume case sensitivity and enforce lowercase exclusively to prevent environment-specific bugs.

Special Cases and Edge Cases

Acronyms in Names

Debate rages over whether "HTTP" should be "Http" in camelCase or "HTTP" in PascalCase. Google's style guides recommend treating acronyms like words: XmlHttpRequest, not XMLHTTPRequest. This avoids ALLCAPS visual noise.

Numbers in Names

Always separate numbers with an underscore or hyphen: user_1 or user-1, not user1. The latter is harder to read and can be ambiguous (is "user1" one word or user + 1?).

Non-English Words

If your codebase includes non-English terms, romanise them consistently. Do not mix scripts — it breaks searchability and tooling.

Emoji and Unicode in Identifiers

Modern JavaScript allows emoji in variable names, but doing so creates tooling nightmares. Most linters, text editors, and code review systems struggle with non-ASCII identifiers. Stick to basic Latin characters for maximum compatibility. If you must include special characters, use Unicode escapes in comments or documentation, never in identifiers.

URL Encoding and Case Sensitivity

URL paths are case-sensitive on most Unix-based servers but case-insensitive on Windows IIS. A kebab-case URL (/user-profile) avoids ambiguity because it contains no uppercase letters. When designing APIs, assume case sensitivity and enforce lowercase exclusively to prevent environment-specific bugs.

Legacy Codebase Migration

Changing conventions in a mature codebase is expensive and risky. If you inherit a project with inconsistent naming, do not attempt to refactor everything at once. Instead, adopt a "boy scout rule" approach: leave code better than you found it. When touching a file, update its naming to the target convention. Over months, the codebase converges without the risk of a massive, error-prone refactoring.

API Design and Consumer Expectations

When designing public APIs, your naming conventions are a contract with consumers. Changing snake_case to camelCase in a released API is a breaking change that requires a major version bump. Choose your conventions before public release and stick to them. If you must change, provide a migration period with both formats supported and clear deprecation warnings.

Conclusion

Consistency matters more than any single convention. Pick a standard for your project, document it, enforce it in code review, and move on. The cognitive load of switching between conventions within one codebase far exceeds any marginal benefit of "the perfect choice." When in doubt, follow the dominant convention of your language ecosystem — it is dominant for a reason.

Need to convert between cases quickly? Use the ReddTools Case Converter — it handles camelCase, snake_case, kebab-case, PascalCase, and more with a single click.