Programming Naming Conventions: The Complete Guide

Quick answer: The six naming conventions you’ll meet in code are camelCase (firstName), PascalCase (FirstName), snake_case (first_name), kebab-case (first-name), CONSTANT_CASE (FIRST_NAME), and dot.case (first.name). Which one to use depends on your language and what you’re naming — variable, class, constant, file, or URL.

Naming conventions are the rules that decide how you combine multiple words into a single identifier. Every language and ecosystem has its own preferences, and following them makes your code readable to other developers and consistent with the libraries you use.

This guide covers all six conventions in depth: what each one is, the exact rules for writing it, where it is the standard, the traps that catch people, and how to convert between them.

The Six Conventions at a Glance

Convention	Example	Primary use
camelCase	getUserName	JS/TS variables, functions, JSON keys
PascalCase	GetUserName	Classes, types, React/Vue components, C# methods
snake_case	get_user_name	Python, Ruby, SQL, Rust variables
kebab-case	get-user-name	URLs, CSS classes, HTML attributes, file names
CONSTANT_CASE	MAX_RETRY_COUNT	Constants, environment variables
dot.case	app.config.json	Config files, namespaces, i18n keys

---

camelCase — Variables and Functions

camelCase joins words with no spaces and capitalizes the first letter of every word except the first: firstName, getUserProfile. The name comes from the visual appearance — the capital letters look like the humps of a camel.

Examples: firstName, backgroundColor, getUserProfile, isLoggedIn, maxRetryCount

Key rule: The first word is entirely lowercase in camelCase. That is the only thing distinguishing it from PascalCase (FirstName, BackgroundColor).

Rules for writing camelCase

1. No spaces or special characters — words are joined directly.
2. First word entirely lowercase — userProfile, not UserProfile.
3. Each subsequent word starts with a capital — firstName, getBackgroundColor.
4. Treat abbreviations as words — ✅ userId, htmlParser, apiKey; ❌ userID, HTMLParser, APIKey (older style, avoid in new code).

Where camelCase is used

JavaScript and TypeScript — the de facto standard for variable names, function names, and object properties:

const userName = 'Alice';
function getUserById(id) {}
const response = { "firstName": "Alice", "lastName": "Smith" };

Java — variables, fields, and methods:

int numberOfStudents = 0;
public void calculateTotal() {}
private String emailAddress;

Go — unexported (private) identifiers use camelCase; exported (public) ones use PascalCase:

func parseConfig() {} // unexported: camelCase
func ParseConfig() {} // exported: PascalCase

Swift and Kotlin — variables and functions follow camelCase; types and classes use PascalCase.

⚠️ CSS vs. JavaScript: CSS uses kebab-case for custom properties (--background-color), but JavaScript uses camelCase for the same values (backgroundColor in React inline styles). This is a constant source of confusion when moving between a stylesheet and a component.

---

PascalCase — Classes and Components

PascalCase (also called UpperCamelCase) capitalizes every word including the first: UserProfile, HttpClient. The name comes from the Pascal programming language; “UpperCamelCase” is the alternative name that makes the contrast with camelCase explicit.

Examples: UserProfile, BackgroundColor, GetUserById, HttpRequestHandler, MyReactComponent

camelCase vs. PascalCase

The only difference is the first letter:

Convention	First letter	Example	Primary use
camelCase	lowercase	userProfile	Variables, functions, methods
PascalCase	Uppercase	UserProfile	Classes, interfaces, types, React components

Rule of thumb: In nearly every modern language — camelCase for variables and functions, PascalCase for types, classes, and components.

Where PascalCase is used

React components — required, not optional. React uses the capitalization of the component name to distinguish DOM elements from custom components:

• <div> → DOM element
• <myButton> → treated as a DOM element, will not render correctly
• <MyButton> → React component ✅

This is enforced by the framework, not merely a convention. A lowercase component name silently fails to render.

Classes in OOP languages:

class DatabaseConnection {}   // TypeScript/JavaScript

public class HttpClient {}    // Java

class UserModel:              # Python — PascalCase for classes only
    pass                      # (Python uses snake_case for methods/variables)

TypeScript interfaces, types, and enums:

interface ApiResponse {
  statusCode: number;
  data: UserProfile;
}

type UserId = string;
enum HttpMethod { GET = 'GET', POST = 'POST' }

C# — a special case. C# uses PascalCase for both public methods and public properties, unlike Java, which uses camelCase for methods. This catches developers moving between the two languages:

public class UserService {
    public string UserName { get; set; }     // PascalCase property
    public void GetUserById(int id) { }      // PascalCase method (C# convention)
}

Rules for writing PascalCase

1. Every word starts with a capital — UserProfile, not Userprofile or userProfile.
2. No separators — no spaces, underscores, or hyphens.
3. Abbreviations as words (modern style) — HttpRequest, ApiClient, HtmlParser. Avoid HTTPRequest or APIClient in new code.
4. Short acronyms (2–3 letters) — IO, DB, ID are sometimes kept fully uppercase, but this varies by codebase. Follow your team’s convention.

⚠️ Common mistake: Writing HTTPSConnection instead of HttpsConnection. The first is harder to parse visually, and the problem compounds when two acronyms collide.

---

snake_case — Python, Ruby, and Databases

snake_case separates words with underscores (_) and uses all lowercase letters: first_name, get_user_by_id. The name comes from the visual resemblance to a snake lying flat — the underscores form a long, low shape between words.

Examples: first_name, background_color, get_user_by_id, is_authenticated, created_at

Rules for writing snake_case

1. Lowercase all letters — user_profile, not User_Profile or USER_PROFILE.
2. Separate words with underscores — get_user_by_id, not getuserbyid.
3. No spaces or hyphens — underscores only.
4. Abbreviations as single lowercase words — html_parser, api_key, user_id.
5. Leading underscores — in Python, _private_method signals internal use. In most other languages, avoid leading underscores unless the language defines a convention for them.

Where snake_case is used

Python — the official standard (PEP 8). Python’s style guide mandates snake_case for variables, functions, methods, and module names:

def get_user_profile(user_id):
    first_name = db.query(user_id).first_name
    return first_name

Ruby — methods and variables:

def calculate_total_price(items)
  items.sum { |item| item.unit_price }
end

SQL database columns. Most databases (PostgreSQL, MySQL, SQLite) use snake_case for table and column names, because SQL is case-insensitive and underscores are cleaner than hyphens inside SQL syntax:

SELECT first_name, last_name, created_at FROM user_profiles;

Rust — the compiler actively enforces snake_case for variables and functions and emits a warning if you use any other convention.

---

kebab-case — URLs, CSS, and Files

kebab-case (also called hyphen-case or spinal-case) writes lowercase words joined with hyphens: user-profile, main-nav. The name comes from the image of words skewered on a kebab stick: words-on-a-skewer.

Examples: user-profile, background-color, main-navigation, blog-post-title, data-user-id

Why you can’t use kebab-case for variables

Unlike camelCase or snake_case, kebab-case cannot be used for variable or function names in most languages. The hyphen is parsed as the subtraction operator:

let user-name = "Alice";  // ❌ parsed as: user minus name
let userName = "Alice";   // ✅ camelCase works

Key rule: kebab-case is for user-visible and markup contexts — URLs, CSS, HTML — not for code identifiers.

Where kebab-case is the standard

Context	Example	Why
URL slugs	/blog/programming-naming-conventions	Google’s recommended format
CSS class names	.btn-primary, .user-card	The de facto CSS convention
HTML data attributes	data-user-id, aria-label	Required by the HTML spec
npm package names	react-dom, eslint-plugin-react	npm naming rules
CLI flags	--dry-run, --max-retries	Standard CLI convention
Web Component tags	<my-element>	Spec requires a hyphen
File names (web)	user-service.ts, 404-not-found.html	Common in web projects

The SEO case for kebab-case URLs

This is the reason writers and marketers care about kebab-case. Google officially recommends hyphens in URLs, not underscores, and the reason is tokenization:

• https://example.com/buy-running-shoes → Google tokenizes this as three separate words — buy, running, shoes. Each can match a search query.
• https://example.com/buy_running_shoes → Google treats buy_running_shoes as one single token that only matches that exact string.

Using hyphens in your URLs makes each word individually indexable, which directly helps your SEO.

How to create a kebab-case URL slug

1. Take your title: “How to Center a Div in CSS”
2. Lowercase everything: “how to center a div in css”
3. Replace spaces with hyphens: how-to-center-a-div-in-css
4. Optionally drop stop words (a, the, of): how-to-center-div-in-css
5. Remove special characters (apostrophes, commas, etc.)

⚠️ Avoid: double hyphens (how--to), trailing hyphens (how-to-), and uppercase letters (How-To). Keep slugs clean, lowercase, and single-hyphenated.

---

CONSTANT_CASE — Constants and Environment Variables

CONSTANT_CASE (also called SCREAMING_SNAKE_CASE) is snake_case written in all uppercase: MAX_RETRIES, DATABASE_URL. It is used for compile-time constants and environment variables across most languages.

const MAX_RETRIES = 3;
const API_BASE_URL = process.env.API_BASE_URL;

MAX_CONNECTIONS = 100
DATABASE_URL = os.environ["DATABASE_URL"]

The all-caps signals to any reader: this value is fixed, do not modify it. It is a convention, not an enforcement — most languages will happily let you reassign a lowercase constant — but it is universally understood.

---

dot.case — Config and Namespaces

dot.case separates lowercase words with dots: app.config.json, user.profile.name.

Used for: configuration file names, Java package fragments, and internationalization (i18n) keys, where the dots express a hierarchy rather than just a word break:

{ "user.profile.title": "Your profile", "user.profile.save": "Save changes" }

---

Naming Conventions by Language

Language	Variables	Functions	Classes	Constants
JavaScript / TypeScript	camelCase	camelCase	PascalCase	CONSTANT_CASE
Python	snake_case	snake_case	PascalCase	CONSTANT_CASE
Java	camelCase	camelCase	PascalCase	CONSTANT_CASE
C#	camelCase	PascalCase	PascalCase	PascalCase
Ruby	snake_case	snake_case	PascalCase	CONSTANT_CASE
Rust	snake_case	snake_case	PascalCase	CONSTANT_CASE
Go	camelCase / PascalCase*	camelCase / PascalCase*	PascalCase	CONSTANT_CASE / PascalCase
Swift / Kotlin	camelCase	camelCase	PascalCase	CONSTANT_CASE
PHP	camelCase	camelCase	PascalCase	CONSTANT_CASE
SQL	snake_case	snake_case	—	—
CSS	kebab-case	—	kebab-case	kebab-case

*In Go, capitalization controls visibility: PascalCase identifiers are exported (public), camelCase are unexported (private). This is enforced by the compiler, not a style preference.

---

The Acronym Debate: parseUrl vs parseURL

One long-running debate is how to handle acronyms in camelCase and PascalCase:

• Treat as a word (modern, recommended): parseUrl, HtmlParser, userId
• Keep fully uppercase (older): parseURL, HTMLParser, userID

Recommendation: Modern style guides (Google, Airbnb) recommend treating acronyms as words (parseUrl). It keeps compound names readable, especially when two acronyms collide — compare parseHTMLURL with parseHtmlUrl.

Whichever you choose, apply it consistently across the whole codebase. A file that mixes userId and userID is worse than one that consistently uses either.

---

Converting Between Conventions

Conversions between these formats come up constantly — a database column becomes a JavaScript property, a blog title becomes a URL slug, an API field becomes a form key. The mechanics are simple in every direction:

1. Split the source identifier into words (on capitals for camel/Pascal, on _ for snake, on - for kebab, on . for dot).
2. Lowercase every word.
3. Rejoin using the target convention’s rule.

first_name → split [first, name] → rejoin as camelCase → firstName.

Common pitfalls when converting

• API mismatches: Python backends return { "first_name": "Alice" } (snake_case); JavaScript frontends expect { firstName: "Alice" } (camelCase). Always check which convention each layer uses and configure your serializer to convert automatically rather than doing it by hand at every call site.
• Underscores in URLs: always use hyphens, never underscores, in URL slugs — for the tokenization reason above.
• Inconsistent acronyms: a round-trip conversion of parseURL may come back as parse_u_r_l if the splitter treats every capital as a word boundary. Pick one acronym style and normalize before converting.
• Leading/trailing separators: _private and --flag need special handling, or you will produce empty word segments.

---

Which Convention Should You Use?

Let the context decide, in this order:

1. The language’s official style guide wins. PEP 8 for Python, Effective Go for Go, the .NET guidelines for C#. These are non-negotiable — linters enforce them and reviewers expect them.
2. The framework’s requirement wins over preference. React components must be PascalCase. Web Component tags must contain a hyphen.
3. The existing codebase wins over your preference. Consistency inside a project beats being right in the abstract.
4. For anything user-visible — URLs, CSS, files — use kebab-case.

---

Convert Between All Conventions Instantly

The case converter shows all of these conventions at once. Paste any phrase or identifier — like get user profile — and instantly see getUserProfile, GetUserProfile, get_user_profile, get-user-profile, GET_USER_PROFILE, and get.user.profile. Copy whichever one your context needs.

It works in both directions: paste first_name and it produces firstName, FirstName, FIRST_NAME, and first-name simultaneously — useful when you are mapping a database schema onto a frontend model.

Related Articles

• What Is Title Case? Rules, Examples, and Style Guides
• What Does Sentence Case Mean?
• How to Clean Up Messy Text