Naming Conventions in Programming — camelCase, snake_case, and Beyond

You open a codebase for the first time and see getUserName, get_user_name, and GetUserName all in the same file. Immediately, you know something went wrong. Naming conventions are one of those things that seem trivial until you work on a team — then they become essential.

Consistent naming is not about personal preference. It is about making code readable for the next person who touches it, which is often your future self six months from now.

Why Naming Conventions Matter

Three things break down when a project lacks consistent naming:

• Readability suffers — When variable styles shift every few lines, your brain wastes cycles parsing the format instead of understanding the logic
• Team collaboration fractures — Pull requests become battlegrounds over style instead of substance. Onboarding new developers takes longer because there is no predictable pattern
• Tooling stops working properly — Linters, auto-complete, code generators, and refactoring tools all rely on predictable naming patterns. Break the convention and you break the tooling

The convention you pick matters far less than picking one and sticking with it. A codebase with consistent snake_case everywhere is infinitely better than one mixing three different styles.

The Complete Guide to Naming Conventions

camelCase

The first word is lowercase, and every subsequent word starts with an uppercase letter. No separators.

// JavaScript / TypeScript
const userName = "Alice";
let itemCount = 42;
function getUserProfile(userId) {
  return fetchData(`/users/${userId}`);
}

Where it is used: JavaScript, TypeScript, and Java use camelCase for variables, function names, and method names. It is also the default in Swift for local variables and function parameters.

camelCase reads naturally in English because the lowercase start signals "this is a regular value, not something special." The uppercase bumps mark word boundaries without any separator characters.

PascalCase

Every word starts with an uppercase letter. Also called UpperCamelCase.

// TypeScript / C#
class UserProfile {
  firstName: string;
  lastName: string;
}

interface DatabaseConnection {
  host: string;
  port: number;
}

// React component
function NavigationBar({ items }: NavProps) {
  return <nav>{/* ... */}</nav>;
}

Where it is used: C# uses PascalCase for almost everything public — classes, methods, properties. TypeScript and JavaScript use it for classes, interfaces, type aliases, and enums. React mandates PascalCase for component names because JSX needs to distinguish components from HTML elements.

In Go, PascalCase has a special meaning: any identifier starting with an uppercase letter is exported (public). This makes the convention functional, not just cosmetic.

snake_case

All words are lowercase, separated by underscores.

# Python
user_name = "Alice"
item_count = 42

def get_user_profile(user_id):
    return fetch_data(f"/users/{user_id}")

class UserProfile:
    def __init__(self, first_name, last_name):
        self.first_name = first_name
        self.last_name = last_name

Where it is used: Python uses snake_case for virtually everything except class names. Ruby follows the same pattern. Rust uses snake_case for variables, functions, and modules. Database schemas almost universally use snake_case for table and column names.

snake_case is arguably the most readable convention because underscores create clear visual separators. The tradeoff is that identifiers are longer.

SCREAMING_SNAKE_CASE

All uppercase with underscores. Reserved for constants and values that should never change.

// Constants in most languages
const MAX_RETRY_COUNT = 3;
const API_BASE_URL = "https://api.example.com";
const DEFAULT_TIMEOUT_MS = 5000;

# Python constants
DATABASE_URL = "postgresql://localhost:5432/mydb"
MAX_FILE_SIZE_BYTES = 104_857_600

// Rust constants
const MAX_CONNECTIONS: u32 = 100;
static APP_VERSION: &str = "2.1.0";

Where it is used: Nearly every language uses SCREAMING_SNAKE_CASE for constants. The all-caps format is a universal signal that says "do not reassign this value." In C, it is also used for preprocessor macros.

kebab-case

All lowercase with hyphens as separators.

/* CSS class names */
.navigation-bar {
  background-color: #1a1a2e;
}

.user-profile-card {
  border-radius: 8px;
}

.btn-primary-large {
  font-size: 1.125rem;
}

<!-- HTML attributes and data attributes -->
<div data-user-id="42" aria-label="main-navigation">
  <input type="text" placeholder="search-query" />
</div>

# CLI flags
npm install --save-dev eslint
git commit --no-verify
docker run --restart=always

Where it is used: CSS and HTML heavily favor kebab-case. URL slugs use it (like this blog post's URL). CLI tools and command-line flags follow it. YAML and TOML configuration keys often use it too.

kebab-case cannot be used for variable names in most programming languages because the hyphen is interpreted as a minus operator. That is why it lives in CSS, HTML, and configuration files rather than in code.

dot.case

Words separated by dots.

// Java package names
package com.example.userservice.controllers;

import org.springframework.boot.SpringApplication;

# Configuration keys
server.port=8080
spring.datasource.url=jdbc:postgresql://localhost/mydb
logging.level.root=INFO

Where it is used: Java package naming, file extensions, configuration property keys in Spring Boot and similar frameworks. Object property access in JavaScript technically uses dot notation, though that is syntax rather than a naming convention.

Title Case

Each major word is capitalized. Minor words like "and," "the," and "of" stay lowercase unless they start the phrase.

User Account Settings
Privacy and Security Options
Getting Started with React

Where it is used: UI headings, page titles, menu items, documentation sections, and proper nouns. It is a presentation convention rather than a code convention. You will not see it in variable names, but it shows up in string constants and UI copy.

path/case

Words separated by forward slashes, following file system or namespace conventions.

src/components/UserProfile
com/example/service/UserAuth
features/authentication/login

Where it is used: File system paths, module paths, namespace hierarchies, and URL routing structures. It is structural rather than stylistic — the slashes represent actual hierarchical relationships.

Language-Specific Convention Table

Here is a quick reference for what each language expects:

The key insight from this table: PascalCase for types and classes is nearly universal. The biggest variation is in how languages handle variables and functions.

Common Mistakes and How to Fix Them

1. Mixing conventions within the same scope

// ❌ Inconsistent
const user_name = "Alice";
const itemCount = 42;
const MaxRetries = 3;

// ✅ Consistent camelCase
const userName = "Alice";
const itemCount = 42;
const maxRetries = 3;

This is the most common mistake. It happens when developers bring habits from one language into another, or when a project has no style guide.

2. Using the wrong convention for the language

# ❌ Using camelCase in Python
def getUserProfile(userId):
    userName = fetchUser(userId)
    return userName

# ✅ Using snake_case as Python expects
def get_user_profile(user_id):
    user_name = fetch_user(user_id)
    return user_name

When you write Python with camelCase, every Python developer reading your code has to mentally translate it. Follow the language's standard — PEP 8 for Python, the Go style guide for Go, and so on.

3. Abbreviations and acronyms

// ❌ Inconsistent acronym handling
const XMLParser = new XmlParser();
const htmlToJSON = convert(HTMLString);
const getAPIUrl = () => apiURL;

// ✅ Treat acronyms as words
const xmlParser = new XmlParser();
const htmlToJson = convert(htmlString);
const getApiUrl = () => apiUrl;

The general rule: treat acronyms as regular words in camelCase and PascalCase. Write getApiUrl not getAPIURL, and XmlParser not XMLParser. This keeps capitalization predictable.

4. Overly short or cryptic names

// ❌ Too short
const n = users.length;
const cb = (err, res) => { /* ... */ };
const tmp = calculate(x, y);

// ✅ Descriptive
const userCount = users.length;
const handleResponse = (error, result) => { /* ... */ };
const totalPrice = calculate(quantity, unitPrice);

The convention is just the casing pattern. The name itself still needs to be descriptive enough that someone reading the code understands the purpose without checking where the variable was assigned.

5. Boolean names without is/has/can prefixes

// ❌ Ambiguous boolean
const active = true;
const admin = false;
const visible = true;

// ✅ Clear boolean intent
const isActive = true;
const isAdmin = false;
const isVisible = true;

Prefixing booleans with is, has, can, or should makes conditional statements read like English: if (isActive) is clearer than if (active).

Automated Conversion Between Conventions

When you are working across languages — maybe converting a Python API response to JavaScript frontend code, or migrating database column names to TypeScript interfaces — manually converting naming conventions is tedious and error-prone.

Our String Case Converter tool handles this automatically. Paste any identifier and convert it between camelCase, PascalCase, snake_case, kebab-case, SCREAMING_SNAKE_CASE, and more with a single click. It is particularly useful when:

• Mapping API response fields (snake_case from Python backends) to frontend variables (camelCase in JavaScript)
• Generating database migration scripts where column names need to follow SQL conventions
• Refactoring code from one language's style guide to another
• Creating consistent naming across a full-stack application

Setting Up Naming Convention Enforcement

Do not rely on code reviews alone to catch naming violations. Automate it:

ESLint for JavaScript/TypeScript:

{
  "rules": {
    "camelcase": ["error", { "properties": "always" }],
    "@typescript-eslint/naming-convention": [
      "error",
      { "selector": "variable", "format": ["camelCase", "UPPER_CASE"] },
      { "selector": "typeLike", "format": ["PascalCase"] }
    ]
  }
}

Pylint for Python:

[FORMAT]
variable-rgx=[a-z_][a-z0-9_]{0,30}$
function-rgx=[a-z_][a-z0-9_]{0,30}$
class-rgx=[A-Z_][a-zA-Z0-9]+$

Clippy for Rust: Rust's clippy linter automatically warns on naming convention violations out of the box. No extra configuration needed.

These tools catch mistakes before they reach code review, saving everyone time and keeping the codebase consistent.

Further Reading

Naming conventions are just one piece of writing clean, maintainable code. For more development best practices, check out:

• JSON Formatting Best Practices — Structure your data as cleanly as you name your variables
• Regex Cheat Sheet — Pattern matching reference for validation and text processing
• SQL Formatting Best Practices — Write readable SQL queries with proper keyword casing and alignment

---

Ready to convert naming conventions automatically? Try our String Case Converter — paste any identifier and transform it between camelCase, snake_case, PascalCase, kebab-case, and more. No sign-up, no data sent to servers, completely free.