Every programmer faces the same small decision dozens of times a day: how do I join two or more words into a single identifier? Spaces are not allowed in variable names, function names, file names, or CSS classes, so the words have to be glued together somehow. The conventions that solve this problem have names of their own, and the most common are camelCase, PascalCase, snake_case, SCREAMING_SNAKE_CASE, and kebab-case. Picking the right one is rarely about correctness and almost always about consistency with the language, framework, and team you are working in.
Why Naming Conventions Matter
A naming convention is a shared agreement about how compound identifiers are written. On its own, getUserProfile is no more valid than get_user_profile or get-user-profile; the compiler does not care. What does care is the human reading the code six months later, and the linter that flags anything that breaks the house style.
Consistency is the real prize. When every variable in a JavaScript file is camelCase and every constant is SCREAMING_SNAKE_CASE, you can tell at a glance what kind of value you are looking at. Mixing styles, on the other hand, creates friction: readers waste mental energy wondering whether the inconsistency is meaningful. Conventions also reduce bugs, because in case-sensitive languages userId and userid are two different identifiers, and a predictable style keeps you from accidentally creating both.
camelCase
In camelCase, the first word is lowercase and every following word starts with a capital letter, with no separators in between. The name comes from the humps the capital letters create in the middle of the word, as in firstName, totalItemCount, or isLoggedIn.
This is the default style for variables and functions in JavaScript and TypeScript, and it is equally standard for variables, methods, and parameters in Java, C#, Kotlin, and Swift. If you are writing front-end code or working in the broader JVM and .NET worlds, camelCase is almost certainly what your linter expects for ordinary identifiers.
PascalCase (UpperCamelCase)
PascalCase is camelCase with one change: the very first letter is also capitalized, so every word begins with an uppercase letter, as in UserProfile, HttpRequestHandler, or InvoiceLineItem. It is sometimes called UpperCamelCase to make the relationship explicit.
The convention is reserved for things that represent a type or a construct rather than a plain value. Classes, interfaces, enums, and type aliases use PascalCase in most languages, and React components must start with a capital letter, which makes PascalCase the standard for component names like NavBar or ProductCard. The capital first letter is how JSX tells the difference between a component and a built-in HTML element. TypeScript types and interfaces follow the same rule.
snake_case
In snake_case, words are entirely lowercase and joined by underscores, as in first_name, total_item_count, or is_logged_in. The underscores stand in for the spaces, giving a low, flat look that some find more readable than the humps of camelCase.
This is the dominant convention for variables and functions in Python and Ruby, where the official style guides recommend it explicitly. It is also the norm for database identifiers: table names and column names in SQL are conventionally snake_case, partly because many databases treat unquoted identifiers as case-insensitive, which makes mixed-case names fragile. If you work in Python, Ruby, Rust (for functions and variables), or relational databases, snake_case will feel like home.
SCREAMING_SNAKE_CASE (CONSTANT_CASE)
SCREAMING_SNAKE_CASE, also called CONSTANT_CASE or UPPER_SNAKE_CASE, takes snake_case and makes every letter uppercase, as in MAX_RETRY_COUNT, API_BASE_URL, or DEFAULT_TIMEOUT_MS. The all-caps shout is a visual signal that the value never changes.
The near-universal use for this style is constants. In JavaScript, Java, Python, C, and most other languages, values that are fixed at definition time are written in SCREAMING_SNAKE_CASE so that readers immediately recognize them as immutable. Environment variables follow the same convention, which is why you see names like DATABASE_URL and NODE_ENV in .env files and deployment configs. When you spot all caps with underscores, you can assume you are looking at a constant or a configuration key.
kebab-case
In kebab-case, words are lowercase and joined by hyphens, as in user-profile, main-nav, or order-summary. The name comes from the words being skewered on hyphens like meat on a kebab. The hyphen makes this style unusable for most programming-language identifiers, because a hyphen is read as a minus sign, so kebab-case lives almost entirely outside source-code variables.
Where it shines is in text that the web reads directly. URL slugs use kebab-case because hyphens are readable and search-engine friendly, which is why this article lives at a hyphenated path. CSS class names and custom HTML attributes conventionally use kebab-case, as do many file and folder names in front-end projects. If you are naming something that a browser, a URL, or a stylesheet will consume, kebab-case is usually the right call.
Which Convention Goes Where
The simplest rule is to follow the ecosystem you are in rather than imposing a personal preference. JavaScript and TypeScript use camelCase for variables and functions, PascalCase for classes, types, and React components, and SCREAMING_SNAKE_CASE for constants. Python and Ruby use snake_case for variables and functions, PascalCase for classes, and SCREAMING_SNAKE_CASE for constants. SQL databases lean on snake_case for tables and columns. The web platform uses kebab-case for URLs, CSS classes, and HTML attributes.
When two ecosystems meet, friction appears. A common example is an API that returns snake_case JSON keys being consumed by a camelCase JavaScript client, which is why so many projects include a small layer that converts keys from one style to the other at the boundary. Knowing the conventions on both sides makes that translation routine instead of confusing.
Tips for Staying Consistent and Converting Between Styles
The first tip is to let tooling enforce the rules so you do not have to think about them. Linters like ESLint and formatters like Prettier, Black, and RuboCop can flag or auto-fix naming that drifts from the project standard, which keeps an entire codebase uniform without manual effort.
The second tip is to convert in bulk rather than by hand when you need to switch a block of identifiers from one style to another, because manual editing is slow and error-prone. The free ToolboxHub Case Converter does exactly this: paste any text and switch it instantly between camelCase, PascalCase, snake_case, SCREAMING_SNAKE_CASE, kebab-case, and more, all in your browser with nothing sent to a server. It is handy for reformatting a list of database columns into JavaScript properties, turning a heading into a URL slug, or normalizing a pasted snippet to match your house style. For the surrounding cleanup, the Word Counter helps you check length limits on slugs and labels, and Remove Duplicate Lines tidies a pasted list of names before you convert it.
Key Takeaways
camelCase lowercases the first word and capitalizes the rest, and it is the default for variables and functions in JavaScript and Java. PascalCase capitalizes every word and is reserved for classes, types, and React components. snake_case joins lowercase words with underscores and rules Python, Ruby, and SQL columns. SCREAMING_SNAKE_CASE shouts in all caps with underscores and marks constants and environment variables. kebab-case joins lowercase words with hyphens and belongs to URLs, CSS classes, and file names. None of these is more correct than the others, so the winning move is to match the convention of your language and framework and stay consistent. When you need to switch text from one style to another, the free ToolboxHub Case Converter does it instantly in your browser.