Naming Conventions in Code: camelCase vs snake_case vs kebab-case Explained

Code naming is one of those topics that seems trivial until you join a new team or read someone else's project. The rules are not arbitrary — each convention has a reason, a language community that adopted it, and tradeoffs. Here's a fast guide to which case style to use when.

The six conventions you'll meet

camelCase — when and why

camelCase is the default for variable and function names in JavaScript, Java, Swift, Kotlin and Go-language (with capitalised first letter for exports). The rule is straightforward: lowercase the first word, capitalise the first letter of every subsequent word, no spaces or separators.

Why camelCase works: it's compact (no separator characters wasted), readable enough for short names, and ergonomic to type without modifier keys.

const userName = "Ada"
function getUserById(id) { ... }

PascalCase — when and why

PascalCase is camelCase with the first letter also capitalised. Universal for type names, class names, and (in React) component names.

class UserAccount { ... }
const UserCard = () => { ... }   // React component
type UserId = string             // TypeScript type

The capital first letter signals "this is a type or class, not a value". React's JSX parser relies on this — lowercase tags are treated as HTML; capitalised tags are treated as components. Get it wrong and your component disappears.

snake_case — when and why

snake_case is the standard in Python, Ruby and PostgreSQL. The underscore separator makes long identifiers more readable than camelCase — your eyes don't have to parse case boundaries.

def get_user_by_id(user_id):
    return db.users.find_one(id=user_id)

PostgreSQL prefers snake_case for column and table names because identifiers are case-insensitive by default. UserName and username are the same column unless you quote it.

SCREAMING_SNAKE_CASE — for constants

Reserved for constants in basically every language. Marks the value as a fixed, named magic number or configuration value:

const MAX_RETRIES = 3
const API_BASE_URL = "https://api.example.com"
SECRET_KEY = "..."   // Python
public static final int MAX_USERS = 100;   // Java

kebab-case — when and why

kebab-case uses hyphens instead of underscores. It's the standard for:

• URLs: /blog/my-post-title. Hyphens beat underscores for SEO (Google treats them as word separators).
• CSS class names: .user-card, .nav-item.
• HTML attributes: data-user-id, aria-label.
• npm package names: my-cool-package.
• CLI flags: --user-name.
• File names: blog-post-title.md.

You can't use kebab-case for variables in most languages because - is the subtraction operator. user-name evaluates to user minus name.

The naming rules nobody writes down

Beyond the case styles, some patterns are universal:

• Boolean naming. Start with is, has, or can: isAdmin, hasError, canEdit. Avoid ambiguous names like admin (number? boolean?).
• Array names are plural. users, not userList or userArray.
• Functions start with a verb. getUser, calculateTotal, renderHeader.
• Single-letter names only for loop indices (i, j) or extremely short scopes.
• Avoid abbreviations that aren't industry standard. amount beats amt. Acceptable: id, url, db.

Language-specific conventions

• JavaScript / TypeScript: camelCase for variables and functions, PascalCase for classes/types/components, SCREAMING_SNAKE for constants.
• Python: snake_case for everything except classes (PascalCase) and constants (SCREAMING_SNAKE).
• Java: camelCase for variables/methods, PascalCase for classes, SCREAMING_SNAKE for constants.
• Go: camelCase for private (lowercase first letter = package-private), PascalCase for exported (uppercase first letter = public).
• Rust: snake_case for variables/functions, PascalCase for types, SCREAMING_SNAKE for constants.
• Ruby: snake_case for variables/methods, PascalCase for classes, SCREAMING_SNAKE for constants.

Database column conventions

• PostgreSQL: snake_case. user_id, created_at.
• MySQL: snake_case by convention, though case-insensitive by default.
• MongoDB: usually camelCase since you're often working with JavaScript drivers.

When mapping from SQL snake_case columns to JS camelCase fields, most ORMs (Prisma, Drizzle, Sequelize) handle the conversion automatically.

Common mistakes

• Mixing conventions in one file. Pick a style and stick with it.
• Using kebab-case for variables. Won't compile in any major language.
• Hungarian notation (strName, iCount). Outdated since IDEs show types. Don't.
• Single-letter constants. K isn't a meaningful name even in math.
• Inconsistent boolean naming. Half your booleans start with is and half are just nouns — pick one approach.

The cheat sheet

• Variable / function in JS, Java, Swift? camelCase.
• Class, type, React component? PascalCase.
• Constant? SCREAMING_SNAKE_CASE.
• Python or Ruby code? snake_case (PascalCase for classes).
• URL slug, CSS class, HTML attribute, npm package? kebab-case.
• Postgres column? snake_case.