Naming Conventions in Programming: camelCase, snake_case, and Beyond

A function called getData in one file, get_data in another, and GetData in a third. We've all inherited codebases like this. Inconsistent naming conventions don't just look messy — they create genuine cognitive overhead. Your brain has to context-switch every time the pattern changes instead of focusing on what the code actually does.

Naming conventions exist to eliminate that friction. Pick one, stick to it, and suddenly your code reads like a coherent document instead of a ransom note.

The Big Four

Most code you'll ever encounter uses one of four conventions. Each has a history, a community, and a set of rules.

camelCase

Starts lowercase, capitalizes subsequent words. No separators.

getUserProfile
calculateTotalPrice
isAuthenticated

This is the default in JavaScript, TypeScript, Java (for methods and variables), and C# (for local variables and parameters). React component props, JSON property names by convention, and most frontend code follow camelCase.

The name is visual — the capital letters in the middle create humps like a camel's back. It's compact and reads naturally once you're used to it, though beginners sometimes find the word boundaries harder to spot.

Convert any text to camelCase when you're moving identifiers into JavaScript or TypeScript code.

snake_case

All lowercase, words separated by underscores.

get_user_profile
calculate_total_price
is_authenticated

Python's PEP 8 mandates this. Ruby, Rust, PHP (partially), and most database schemas use it too. If you write SQL, your column names are probably snake_case.

The underscores act as visual spaces, making word boundaries obvious at a glance. It's slightly more verbose than camelCase but arguably easier to scan, especially for longer identifiers.

The snake_case converter handles tricky edge cases like acronyms and numbers automatically.

PascalCase

Like camelCase, but the first letter is also capitalized.

GetUserProfile
CalculateTotalPrice
HttpClientFactory

PascalCase (sometimes called "upper camel case") is the convention for class names in nearly every language. In C#, it's used for everything public — methods, properties, and types. React components must use PascalCase to distinguish them from HTML elements.

The rule is straightforward: if it's a class, interface, type, or React component, capitalize the first letter.

kebab-case

All lowercase, words separated by hyphens.

get-user-profile
calculate-total-price
is-authenticated

You'll see this in CSS class names, HTML attributes, URL slugs, CLI flags, and package names. It's the convention of the web outside of JavaScript.

.user-profile-card { }
.is-active { }
.btn-primary { }

Kebab-case reads cleanly in URLs: /user-profile/settings looks better than /user_profile/settings or /userProfile/settings. Our Slugify tool generates clean kebab-case URLs from any text.

Less Common But Still Important

SCREAMING_SNAKE_CASE

Uppercase with underscores. Used almost universally for constants and environment variables.

MAX_RETRY_COUNT
DATABASE_URL
API_BASE_PATH
NODE_ENV

This isn't just style — it's a signal. When you see all caps with underscores, you immediately know it's a value that shouldn't change at runtime.

COBOL-CASE (SCREAMING-KEBAB)

Uppercase with hyphens: CONTENT-TYPE, X-FORWARDED-FOR. You'll mainly see this in HTTP headers (though the spec is technically case-insensitive).

Which Convention for Which Language?

Here's a practical cheat sheet:

| Language | Variables/Functions | Classes/Types | Constants | Files | |----------|-------------------|---------------|-----------|-------| | JavaScript/TS | camelCase | PascalCase | SCREAMING_SNAKE | kebab-case | | Python | snake_case | PascalCase | SCREAMING_SNAKE | snake_case | | Ruby | snake_case | PascalCase | SCREAMING_SNAKE | snake_case | | Java | camelCase | PascalCase | SCREAMING_SNAKE | PascalCase | | C# | camelCase (local) | PascalCase | PascalCase | PascalCase | | Go | camelCase/PascalCase | PascalCase | PascalCase | snake_case | | Rust | snake_case | PascalCase | SCREAMING_SNAKE | snake_case | | CSS | kebab-case | — | — | kebab-case |

The most common source of convention conflicts? Moving data between languages. A Python API sends user_name, your React frontend expects userName, and your CSS classes use user-name. Same concept, three representations.

The Conversion Problem

When you're working across system boundaries, you constantly need to convert between conventions. A few real scenarios:

API serialization. Your Python backend uses snake_case, but the mobile team wants camelCase in the JSON responses. You either configure your serializer (Django REST Framework's CamelCaseJSONRenderer, for example) or convert manually.

Database mapping. ORM models map created_at columns to createdAt properties. Most ORMs handle this, but if you're writing raw SQL alongside application code, you're doing mental gymnastics.

Component libraries. A UI library uses PascalCase component names with camelCase props, wrapped in kebab-case CSS classes. Totally normal, but you need to keep track of which layer you're in.

For one-off conversions, tools beat manual rewriting. Paste a list of snake_case database columns and convert them to camelCase for your TypeScript interfaces. Or take camelCase variable names and convert to snake_case when writing Python bindings.

Acronyms: The Edge Case Everyone Gets Wrong

How do you handle HTML, API, or URL in different conventions?

// Option A: Treat acronym as a word
htmlParser → html_parser → HtmlParser

// Option B: Keep acronym uppercase
HTMLParser → html_parser → HTMLParser

Most modern style guides lean toward Option A. JavaScript's XMLHttpRequest is a relic of the old approach — newer APIs use fetch partly to avoid this exact debate. TypeScript's compiler API uses getLineAndCharacterOfPosition, not getLineAndCharacterOfPosition — wait, that already follows the rule. But React's dangerouslySetInnerHTML keeps "HTML" as "HTML" in the property name. It's a mess.

The safest rule: treat acronyms as regular words in camelCase and PascalCase. So apiUrl not aPIURL, htmlElement not hTMLElement.

File Naming

File naming conventions vary more than variable naming, and they matter because file systems have different case sensitivity rules.

Linux file systems are case-sensitive: UserProfile.tsx and userProfile.tsx are different files. macOS and Windows are case-insensitive by default: they'll happily let you import ./UserProfile as ./userProfile, then break on the CI server running Linux.

The safest approach for cross-platform projects:

• React components: PascalCase.tsx (matches the component name)
• Everything else: kebab-case.ts or snake_case.ts
• Never rely on case differences to distinguish files

Enforcing Conventions

Having a convention means nothing if it's not enforced. Practical enforcement options:

Linters. ESLint's @typescript-eslint/naming-convention rule, Pylint's naming checks, and RuboCop's naming cops all catch violations automatically.

Pre-commit hooks. Run naming checks before code enters the repository.

Code review. The human layer. Automated tools catch the obvious stuff; reviewers catch the semantic issues like misleading names.

Try It Yourself

Stop manually rewriting identifiers when moving code between systems. Our conversion tools handle the transformation cleanly:

• camelCase Converter — for JavaScript, TypeScript, and JSON
• snake_case Converter — for Python, Ruby, and databases
• Title Case Converter — for PascalCase-style formatting
• Slugify — for URLs and kebab-case identifiers

All processing happens in your browser. Nothing gets sent to a server.