camelCase vs snake_case vs kebab-case: Naming Conventions Explained

If you've ever opened someone else's codebase and immediately noticed that variables look different from what you're used to — getUserName in one project, get_user_name in another, get-user-name in a URL — you've encountered the naming convention question. It sounds trivial. It isn't. Naming conventions affect code readability, tooling compatibility, cross-language interoperability, and even SEO. Choosing the wrong one doesn't break your code, but it creates friction for every person (and every machine) that reads it afterward.

This guide covers the most common conventions — camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE, and dot.case — explains where each one came from, which languages and frameworks mandate them, and how to convert between them when you need to.

The Conventions at a Glance

camelCase starts with a lowercase letter and capitalizes the first letter of each subsequent word: firstName, getUserById, isActive. The name comes from the "humps" formed by the capital letters in the middle of the word. It's the dominant convention in JavaScript, TypeScript, Java (for methods and variables), and Swift.

PascalCase (also called UpperCamelCase) capitalizes the first letter of every word, including the first: FirstName, GetUserById, HttpClient. It's used for class names in almost every object-oriented language, for component names in React and Angular, and as the general convention for public members in C# and .NET.

snake_case uses lowercase letters with words separated by underscores: first_name, get_user_by_id, is_active. It's the standard in Python (mandated by PEP 8), Ruby, Rust, and most SQL dialects. It's also the most common convention in C standard library functions, though C itself doesn't enforce a style.

kebab-case uses lowercase letters with words separated by hyphens: first-name, get-user-by-id, is-active. It's the standard for CSS class names and custom properties, HTML attributes, URL slugs, npm package names, and CLI flags. You can't use it as a variable name in most programming languages because the hyphen is interpreted as a minus operator, which is why it's confined to configuration, markup, and URLs.

CONSTANT_CASE (also called SCREAMING_SNAKE_CASE) uses uppercase letters with underscores: MAX_RETRIES, API_BASE_URL, DEFAULT_TIMEOUT. It's used for constants across nearly every language — JavaScript, Python, Java, C, Go, Rust.

dot.case separates words with periods: com.example.app, user.profile.settings. It's primarily seen in Java package names, configuration file keys (like properties files), and some logging frameworks. Our dot case converter handles this format.

Why Conventions Exist (It's Not Just Aesthetics)

Naming conventions exist because code is read far more often than it's written. A consistent convention acts as metadata: when you see MAX_RETRIES, the screaming snake case tells you it's a constant before you even look at its declaration. When you see UserProfile in PascalCase in a React file, you know it's a component, not a utility function. When you see is_valid in a Python file, the snake case confirms it follows the project's style guide.

Consistency within a codebase reduces cognitive load. A developer doesn't have to think about whether it's getUser, get_user, or GetUser — the convention answers that question automatically. This is why linters and formatters enforce naming rules: ESLint can flag camelCase violations in JavaScript, Pylint flags non-snake_case variables in Python, and RuboCop does the same for Ruby.

Inconsistency, on the other hand, creates bugs. In a case-sensitive language, userName and username and UserName are three different identifiers. Mixing conventions in the same project means developers waste mental cycles remembering which style was used where, and inevitably get it wrong.

Convention by Language: The Authoritative Sources

JavaScript and TypeScript use camelCase for variables, functions, and methods; PascalCase for classes and React/Angular components; and CONSTANT_CASE for module-level constants. This is documented in the Google JavaScript Style Guide, the Airbnb JavaScript Style Guide, and the MDN JavaScript guidelines. TypeScript follows the same conventions, with PascalCase also used for type aliases, interfaces, and enums. Our camelCase converter can reformat text from any other convention into JavaScript-style camelCase.

Python mandates snake_case for functions, methods, variables, and module names, and PascalCase for class names. This comes from PEP 8, Python's official style guide, which states: "Function names should be lowercase, with words separated by underscores as necessary to improve readability." Constants use CONSTANT_CASE. PEP 8 is enforced by tools like Pylint, Flake8, and Black. Convert text to Python-style naming with our snake case converter.

Java uses camelCase for methods and variables, PascalCase for classes and interfaces, and CONSTANT_CASE for static final constants. Package names are all lowercase with dots as separators (e.g., com.example.utils). These conventions are defined in the Java Code Conventions and the Google Java Style Guide.

C# and the broader .NET ecosystem use PascalCase for nearly everything public — classes, methods, properties, and namespaces. Private fields commonly use camelCase with an underscore prefix (_firstName). This is documented in Microsoft's .NET naming guidelines. Use our Pascal case converter to transform text to .NET-style names.

Go uses PascalCase for exported (public) identifiers and camelCase for unexported (private) identifiers. This isn't just a convention — Go's visibility model is enforced by the compiler based on whether the first letter is capitalized. The convention is documented in Effective Go and the Go Code Review Comments.

Rust uses snake_case for functions, methods, variables, and modules; PascalCase for types, traits, and enums; and SCREAMING_SNAKE_CASE for constants and statics. Rust's compiler (rustc) actually emits warnings if you violate these conventions — it's one of the few languages that enforces naming style at the compiler level.

CSS and HTML use kebab-case for class names, IDs, custom properties (--primary-color), data attributes (data-user-id), and HTML tag attributes. This convention predates formal documentation — it's simply how the web was built. BEM notation (block__element--modifier) is a popular extension that adds double underscores and double hyphens. Convert any text to URL-safe kebab-case with our kebab-case converter.

Ruby follows snake_case for methods, variables, and file names, PascalCase for classes and modules, and SCREAMING_SNAKE_CASE for constants. This is documented in the Ruby Style Guide.

SQL traditionally uses UPPERCASE for keywords (SELECT, FROM, WHERE) and snake_case for table and column names (user_accounts, created_at). Though SQL is case-insensitive for keywords, this convention is nearly universal in practice.

URLs, Slugs, and SEO

For URLs and URL slugs, kebab-case is the clear winner. Google's Search Central documentation recommends using hyphens to separate words in URLs rather than underscores, because Google treats hyphens as word separators but treats underscores as word joiners. The URL /blog/camelcase-vs-snakecase-vs-kebabcase is parsed by search engines as three separate terms; /blog/camelcase_vs_snakecase_vs_kebabcase might be treated as a single token.

This is why our slug generator produces kebab-case output by default: it lowercases your text, replaces spaces with hyphens, and strips non-URL-safe characters. If you're building a CMS, blog, or any system that generates URLs from titles, kebab-case slugs are the standard practice.

REST API endpoint design follows the same principle. Most API design guides — including those from Google, Microsoft, and Zalando — recommend kebab-case for URL paths (/api/user-profiles/123) and either camelCase or snake_case for JSON request/response body fields, depending on the ecosystem. JavaScript-heavy APIs (like those consumed by React frontends) tend to use camelCase in JSON bodies. Python and Ruby APIs tend to use snake_case. Pick one and be consistent across all endpoints.

Converting Between Conventions

In real-world development, you frequently need to convert between conventions. Common scenarios include importing data from a snake_case Python API into a camelCase JavaScript frontend, converting PascalCase C# model properties to kebab-case CSS class names, generating URL slugs from article titles, and renaming files or database columns during a refactoring.

The conversion process follows a predictable pattern: first, split the input into individual words by detecting boundaries (capital letters, underscores, hyphens, dots, spaces); then, rejoin the words using the target convention's rules.

For example, converting getUserProfile (camelCase) to snake_case: split on capital letters to get [get, User, Profile], lowercase everything to get [get, user, profile], join with underscores to get get_user_profile. Converting the same input to kebab-case: same split, same lowercase, join with hyphens to get get-user-profile. Converting to PascalCase: same split, capitalize first letter of each word, join directly to get GetUserProfile.

Our suite of case conversion tools handles all of these: camelCase converter, PascalCase converter, snake_case converter, kebab-case converter, dot.case converter, path/case converter, and CONSTANT_CASE converter. You can also use the slug generator specifically for URL-safe output.

Edge Cases and Gotchas

Naming conventions hit complications with acronyms, numbers, and single-letter words. Is an HTTP client called HTTPClient, HttpClient, or httpClient? Style guides disagree. The Google JavaScript Style Guide treats acronyms as regular words — HttpClient, xmlParser, getUrl — while older Java code tends to keep acronyms uppercase (HTTPClient, XMLParser). The Google approach is becoming dominant because it creates less ambiguity: if you uppercase all of "HTTP," then HTTPSConnection is confusing (is it "HTTPS Connection" or "HTTP SConnection"?), but HttpsConnection is clear.

Numbers in identifiers create another challenge. Is it base64Decode or base64_decode? Most conventions treat numbers as part of the preceding word segment, so base64 stays together as one unit. Our Base64 encoder/decoder uses kebab-case in its URL slug (base64-encode-decode) for exactly this reason.

Single-letter words and prepositions can also be tricky. In title case, style guides debate whether words like "a," "to," and "in" get capitalized (see our article on title case conversion for a deep dive). In code naming conventions, though, every word segment is treated the same regardless of length: convertToJson, convert_to_json, convert-to-json.

Enforcing Conventions in Your Project

Don't rely on humans to enforce naming conventions — use tools. For JavaScript and TypeScript, ESLint's @typescript-eslint/naming-convention rule lets you specify exactly which format is required for variables, functions, classes, interfaces, type aliases, and more. For Python, Pylint checks PEP 8 compliance by default. For Ruby, RuboCop includes naming checks. For CSS, Stylelint can enforce kebab-case class names.

Beyond linters, code formatters like Prettier (JavaScript/TypeScript), Black (Python), and rustfmt (Rust) handle some aspects of naming normalization. And if you're working with data interchange — say, transforming a snake_case JSON API response into camelCase for your JavaScript frontend — libraries like camelcase-keys and snakecase-keys in Node.js, or Python's humps library, automate the conversion at the data layer.

The Bottom Line

There is no universally "best" naming convention. The best convention is the one your language, framework, and team have standardized on. Python means snake_case. JavaScript means camelCase. CSS means kebab-case. URLs mean kebab-case. Constants mean SCREAMING_SNAKE_CASE. Classes mean PascalCase in almost every language.

When you're working across boundaries — consuming a Python API from a JavaScript frontend, generating URLs from database fields, refactoring across languages — you'll need to convert between conventions. That's not a problem to solve once; it's a recurring part of multi-language, multi-platform development. Having reliable conversion tools available, whether in your editor, your build pipeline, or as quick online utilities, makes that process frictionless.

References

PEP 8 — Style Guide for Python Code — Python's official naming and style conventions.

Google JavaScript Style Guide — Google's camelCase and PascalCase rules for JavaScript, including acronym handling.

Google Java Style Guide — Java naming conventions for classes, methods, constants, and packages.

Effective Go — Names — Go's convention and the visibility implications of PascalCase vs camelCase.

Microsoft .NET Naming Guidelines — PascalCase conventions for the .NET ecosystem.

Google Search Central — URL Structure — Why hyphens are preferred over underscores in URLs.