camelCase, snake_case, PascalCase: A Developer Guide to Naming Conventions
Naming things is one of the hardest problems in programming. At least the casing part has clear rules.
Every programming language and framework has its own conventions for naming variables, functions, classes, and files. Using the wrong convention will not break your code, but it will make it harder to read, harder to maintain, and harder for other developers to work with. Consistent naming is one of the most visible markers of code quality.
This guide covers the most common naming conventions, explains which languages and contexts prefer each one, and shows you how to convert between them efficiently.
camelCase
In camelCase, the first word is lowercase, and every subsequent word starts with an uppercase letter. There are no spaces, hyphens, or underscores. The name comes from the "humps" created by the uppercase letters in the middle of the word, resembling a camel's back.
Examples: getUserName, totalItemCount, isValid, handleClick.
camelCase is the dominant convention in JavaScript, TypeScript, Java, and C# (for local variables and parameters). In JavaScript, nearly everything uses camelCase: variable names, function names, object properties, and method names. React component props and event handlers follow the same pattern (onClick, className, onChange).
The main advantage of camelCase is compactness. Without separators, names are shorter, which matters in languages where you reference the same variable many times. The trade-off is that very long names can be harder to parse visually — numberOfItemsInShoppingCart requires more mental effort than its snake_case equivalent.
PascalCase (Upper Camel Case)
PascalCase is identical to camelCase except the first letter is also capitalized. Every word starts with an uppercase letter, with no separators. It is sometimes called "Upper Camel Case" to distinguish it from the lowercase-first variant.
Examples: UserProfile, ShoppingCart, HttpRequest, DatabaseConnection.
PascalCase is the standard for class names in virtually every object-oriented language: Java, C#, Python, JavaScript, TypeScript, PHP, and Swift all use it for classes. In C#, PascalCase extends to method names, properties, and public members as well, making it the most pervasive convention in the .NET ecosystem. React and other component-based frameworks use PascalCase for component names to distinguish them from regular HTML elements.
snake_case
In snake_case, all letters are lowercase, and words are separated by underscores. The name comes from the visual resemblance to a snake crawling along the ground.
Examples: user_name, total_item_count, is_valid, get_user_name.
Python is the most prominent snake_case language. PEP 8, Python's official style guide, mandates snake_case for function names, variable names, and module names. Ruby follows the same convention. In database design, snake_case is the overwhelming standard for table and column names across PostgreSQL, MySQL, and SQLite.
snake_case is often considered the most readable convention because the underscores create clear visual separation between words. Studies on code readability have shown that snake_case identifiers are parsed slightly faster by developers who are not already habituated to a different convention. The trade-off is verbosity — underscores add characters, and in deeply nested code, the extra width can push lines beyond comfortable lengths.
SCREAMING_SNAKE_CASE
SCREAMING_SNAKE_CASE (or UPPER_SNAKE_CASE) combines uppercase letters with underscore separators. It is used almost exclusively for constants — values that are defined once and never change during program execution.
Examples: MAX_RETRY_COUNT, API_BASE_URL, DEFAULT_TIMEOUT, HTTP_STATUS_OK.
This convention is universal across languages. Java, Python, JavaScript, C, C++, Go, Rust, and virtually every other language use SCREAMING_SNAKE_CASE for constants. The all-caps styling serves as an immediate visual signal: "this value does not change." Environment variables also follow this convention by tradition (DATABASE_URL, NODE_ENV, HOME).
kebab-case
kebab-case uses lowercase letters with hyphens as separators. The name comes from the visual image of words skewered on a kebab stick.
Examples: user-profile, main-content, nav-bar, text-repeater.
You will not find kebab-case in most programming languages because hyphens are interpreted as minus operators. However, it dominates in web technologies: CSS class names, HTML attributes, URL slugs, and file names in many web projects all use kebab-case. The convention also appears in component libraries (Angular uses kebab-case for selectors), configuration files (YAML, TOML), and command-line flags (--output-dir, --no-cache).
Convention by Language: Quick Reference
| Language | Variables/Functions | Classes | Constants |
|---|---|---|---|
| JavaScript / TypeScript | camelCase | PascalCase | SCREAMING_SNAKE |
| Python | snake_case | PascalCase | SCREAMING_SNAKE |
| Java | camelCase | PascalCase | SCREAMING_SNAKE |
| C# | camelCase / PascalCase | PascalCase | SCREAMING_SNAKE |
| Ruby | snake_case | PascalCase | SCREAMING_SNAKE |
| Go | camelCase | PascalCase | PascalCase / camelCase |
| Rust | snake_case | PascalCase | SCREAMING_SNAKE |
| CSS | kebab-case | — | — |
Why Consistency Matters More Than Choice
Debates about "the best" naming convention miss the point. Within a single project, consistency is what matters. A codebase that uses camelCase everywhere is easier to navigate than one that mixes camelCase and snake_case unpredictably. Most style guides and linters enforce a single convention precisely because the cognitive overhead of switching between styles slows developers down.
When joining an existing project, adopt whatever convention is already in place — even if it is not your personal preference. When starting a new project, follow the conventions of your chosen language. And when you need to convert between conventions (moving data between a Python backend and a JavaScript frontend, for example), use a case converter tool to do it quickly and accurately rather than renaming things by hand.
Beyond Case: General Naming Principles
Good naming goes beyond just picking the right case convention. Use descriptive names that reveal intent: remainingAttempts is better than ra, and isEmailValid is better than flag. Boolean variables should read as questions (hasAccess, isLoading, canEdit). Functions should describe actions (fetchUserData, calculateTotal, validateInput).
Avoid abbreviations that are not universally understood. btn for "button" is widely recognized, but cstmr for "customer" will confuse new team members. When in doubt, spell it out. The extra characters cost nothing at runtime and save significant time during code review and debugging.