Naming Conventions: The Complete Guide to Case Styles in Programming

The naming convention argument I finally settled

Early in my career, I had strong opinions about naming conventions. camelCase was obviously superior. Anyone using snake_case was wrong. Then I started working with Python developers who felt equally strongly in the opposite direction.

After years of these debates, I've realized something: the specific convention matters far less than consistency. A codebase using snake_case consistently is infinitely better than one mixing styles randomly. The 'right' choice is whatever your team agrees on and sticks to.

That said, understanding different conventions and their origins helps you make informed choices. Let me break down each style and when it makes sense to use it.

camelCase: the JavaScript standard

camelCase starts lowercase and capitalizes each subsequent word: getUserName, calculateTotalPrice, isValidEmail. It's the dominant convention in JavaScript, Java, and TypeScript ecosystems.

The name comes from the humps - capital letters in the middle that look like a camel's back. Some call it 'medial capitals' in more formal contexts, but nobody actually says that.

I use camelCase for all JavaScript/TypeScript code because it's what the ecosystem expects. React components use it for props, Node.js uses it for module exports, and most npm packages follow it. Fighting the convention creates friction.

• Common in: JavaScript, TypeScript, Java, C#
• Used for: Variables, functions, methods, object properties
• Example: const userAccountBalance = getUserBalance(userId);
• Pros: Compact, no special characters, widely recognized
• Cons: Can be hard to read with long names or acronyms (XMLHTTPRequest)

PascalCase: for classes and components

PascalCase (also called UpperCamelCase) capitalizes the first letter too: UserProfile, HttpClient, DatabaseConnection. It's camelCase's formal cousin, used for 'important' things like classes and types.

In JavaScript and TypeScript, PascalCase signals 'this is a constructor or class'. When I see const user = new UserAccount(), the capitalization immediately tells me UserAccount is a class I'm instantiating.

React enforces this for components - they must start with a capital letter. Lower case names are treated as HTML elements. UserProfile is a component; userProfile would be parsed as an unknown HTML tag.

• Common in: JavaScript/TypeScript (classes), React (components), C#
• Used for: Classes, interfaces, types, React components, constructors
• Example: class UserAuthentication implements AuthProvider {}
• Pros: Clearly distinguishes classes from instances
• Cons: Some find mixing with camelCase visually inconsistent

snake_case: Python and databases

snake_case uses underscores between words, all lowercase: user_name, get_total_price, is_valid_email. It's the standard in Python and common in database column names.

Python's PEP 8 style guide mandates snake_case for functions and variables. When I write Python, I switch to snake_case without thinking - it's what Python code looks like, and fighting it makes your code look foreign.

Database conventions vary, but snake_case is common because many databases are case-insensitive. user_name works everywhere; userName might become username or USERNAME depending on the database.

• Common in: Python, Ruby, PHP, SQL databases, REST APIs
• Used for: Variables, functions, database columns, API parameters
• Example: def get_user_by_id(user_id): return users_table.find(user_id)
• Pros: Clear word separation, works in case-insensitive contexts
• Cons: Longer than camelCase, harder to type quickly

SCREAMING_SNAKE_CASE: constants that shout

SCREAMING_SNAKE_CASE (or UPPER_SNAKE_CASE) is snake_case in all caps: MAX_RETRY_COUNT, API_BASE_URL, DEFAULT_TIMEOUT_MS. It screams 'I am a constant - do not change me!'

The visual distinction is intentional. When scanning code, constants should stand out. They represent values that are set once and never modified, often configuration or magic numbers that deserve explanation.

I use this for true constants - values that are genuinely constant across the application. Environment-specific configuration? That's not SCREAMING_SNAKE_CASE because it varies. Mathematical constants like PI or MAX_INT? Perfect candidates.

• Common in: Most languages for constants
• Used for: Constants, environment variables, configuration keys
• Example: const MAX_UPLOAD_SIZE_MB = 10; const API_TIMEOUT_MS = 30000;
• Pros: Impossible to miss, clearly communicates immutability
• Cons: Can be overwhelming if overused

kebab-case: URLs and CSS

kebab-case uses hyphens between words: user-profile, get-total-price, is-valid-email. It's called kebab-case because the words look like food on a skewer. Yes, we developers name things strangely.

You'll see kebab-case primarily in URLs and CSS. URLs use hyphens because they're URL-safe and readable: /user-profile/settings is cleaner than /user_profile/settings or /userProfile/settings.

CSS class names traditionally use kebab-case: .nav-menu, .user-avatar, .btn-primary. This convention predates modern frameworks and remains standard in CSS methodologies like BEM.

• Common in: URLs, CSS, HTML attributes, CLI arguments
• Used for: URL slugs, CSS classes, file names, command-line flags
• Example: /api/user-accounts/123/payment-methods
• Pros: URL-safe, very readable, SEO-friendly for URLs
• Cons: Cannot be used for variable names in most languages (hyphen is minus)

When conventions collide: crossing boundaries

The tricky part is when systems with different conventions interact. Your JavaScript frontend uses camelCase, but your Python API returns snake_case. Your database columns are snake_case, but your ORM converts them to camelCase. What do you do?

I've settled on converting at boundaries. The API layer transforms snake_case responses to camelCase for the frontend. The ORM maps snake_case columns to camelCase properties. Each layer uses its native convention internally.

The Case Converter tool is invaluable here. When I'm writing API transformation logic or debugging why a field isn't mapping, I can quickly convert between formats to verify my assumptions.

• Convert at system boundaries, not throughout the codebase
• APIs: Consider accepting both formats for input
• ORMs: Usually handle conversion automatically
• Serialization libraries: Most support case transformation options
• Document your conversion strategy so the team knows what to expect

Team consistency beats personal preference

Here's the advice I wish someone gave me earlier: adopt your team's conventions, even if you disagree. Code style debates are bikeshedding - they feel important but rarely affect outcomes.

When I join a new project, I spend 10 minutes reading the existing code to understand the conventions. Then I follow them exactly. Introducing my preferred style would create inconsistency, which is worse than 'wrong' conventions.

If there are no established conventions, propose something and get team buy-in before writing code. Document it. Add linting rules to enforce it. Then everyone follows the same standard, and style arguments disappear from code reviews.

• Follow existing conventions in established codebases
• Propose and document conventions for new projects
• Use linters and formatters to automate enforcement
• Save debate energy for architectural decisions that matter
• Consistency within a project trumps global best practices

My practical recommendations

After working across many languages and teams, here are the conventions I recommend - not because they're objectively best, but because they match ecosystem expectations and minimize friction.

For JavaScript/TypeScript: camelCase for variables and functions, PascalCase for classes and React components, SCREAMING_SNAKE_CASE for constants. This matches what you'll see in libraries and documentation.

For Python: snake_case for everything except classes (PascalCase). Follow PEP 8. It's not just a guideline - it's how Python is meant to look, and tools like Black enforce it.

For databases: snake_case for everything. It's the safest choice across different database systems and avoids case-sensitivity surprises.

For URLs and files: kebab-case. It's URL-safe, readable, and SEO-friendly. My file names all look like this: case-converter-guide.md, not CaseConverterGuide.md.