camelCase, snake_case, kebab-case - why do we have so many? Here's what I've learned about naming conventions, when to use each style, and why consistency matters more than the 'right' choice.
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 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.
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.
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.
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.
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.
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.
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.
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.
Honestly, none is objectively best - they're all readable once you're used to them. Use what your language ecosystem expects: camelCase for JavaScript, snake_case for Python, etc. Fighting conventions creates friction without any benefit.
Historical reasons, mostly. JavaScript was influenced by Java which uses camelCase. Python's creator Guido van Rossum preferred snake_case and codified it in PEP 8. Both are equally valid; they're just different traditions.
For quick conversions, the Case Converter tool handles all common formats. For code, most languages have libraries - in JavaScript, lodash has camelCase/snakeCase functions. Many API clients have built-in case transformation options.
I prefer snake_case in APIs because it works across all clients without conversion issues. But many modern APIs use camelCase, especially those primarily consumed by JavaScript frontends. Pick one and document it; consistency matters most.
This is surprisingly controversial. XMLHTTPRequest or XmlHttpRequest? I follow the style guide of my language - JavaScript's convention is XmlHttpRequest (treat acronyms as words), while some guides prefer keeping acronyms uppercase. Just be consistent.
Not at all. The runtime doesn't care about variable names - it's purely for human readability. Minifiers will rename everything to single letters anyway. Choose conventions for readability and consistency, not performance.
Founder of CodeUtil. Web developer building tools I actually use. When I'm not coding, I experiment with productivity techniques (with mixed success).
After pasting sensitive API responses into random online tools for years, I finally did a proper comparison. Here's what I actually use now and why privacy matters more than features.
Learn what UUIDs are, understand the differences between UUID versions (v1-v5), when to use each version, and how to generate UUIDs in JavaScript, Python, Go, and Java.
Learn SQL formatting conventions that make your queries easier to read, maintain, and debug. Covers indentation, keyword casing, JOIN formatting, subqueries, and establishing team standards.