camelCase vs snake_case: Which to Use and When

What Are Naming Conventions and Why Do They Matter?

A naming convention is a set of rules for how you write multi-word identifiers — variable names, function names, class names, file names, and so on. Since most programming languages do not allow spaces in identifiers, developers use a special character or capitalisation pattern to separate words.

Naming conventions matter for three practical reasons. First, readability — consistent naming makes code easier to scan and understand, especially for someone reading it for the first time. Second, team consistency — when a whole codebase follows one convention, every file looks familiar regardless of who wrote it. Third, correctness — in some contexts, the wrong convention is not just a style issue, it is a bug. A CSS class named myButton will not match a stylesheet that uses my-button.

The 5 Naming Conventions Explained

There are five conventions you will encounter regularly as a developer. Here is a clear breakdown of each:

Language-by-Language Rules: The Complete Guide

The right convention depends entirely on what language you are working in and what you are naming. Here is the definitive reference for the most common languages:

JavaScript and TypeScript

JavaScript TypeScript

JavaScript has no built-in enforced style, but the community has broadly converged on these rules — reflected in both the Airbnb and Google style guides:

• Variables and functions: camelCase — getUserData(), isLoggedIn
• Classes and constructors: PascalCase — UserProfile, HttpClient
• Constants: CONSTANT_CASE — MAX_RETRIES, API_BASE_URL
• File names: kebab-case or camelCase — user-profile.js or userProfile.js
• React components: PascalCase — UserCard.jsx, NavBar.tsx

// JavaScript naming in practice
const MAX_CONNECTIONS = 10;          // CONSTANT_CASE
let userFirstName = 'Alice';          // camelCase variable

function getUserProfile(userId) {     // camelCase function
  return fetch(`/api/users/${userId}`);
}

class UserProfile {                   // PascalCase class
  constructor(name) {
    this.name = name;
  }
}

Python

Python

Python's official style guide, PEP 8, is explicit and widely followed. Python is one of the few languages that uses snake_case for most identifiers rather than camelCase:

• Variables and functions: snake_case — get_user_data(), is_logged_in
• Classes: PascalCase — UserProfile, HttpClient
• Constants (module-level): CONSTANT_CASE — MAX_RETRIES, BASE_URL
• Private members: prefix with underscore — _internal_method()
• File names and modules: snake_case — user_profile.py

# Python naming in practice (PEP 8)
MAX_RETRIES = 3                        # CONSTANT_CASE
user_first_name = 'Alice'              # snake_case variable

def get_user_profile(user_id):         # snake_case function
    return db.query(user_id)

class UserProfile:                     # PascalCase class
    def __init__(self, name):
        self.name = name

CSS and HTML

CSS

CSS class names and HTML attributes use kebab-case as the near-universal standard. This is enforced by most linters and style guides including Google's HTML/CSS guide:

• CSS class names: kebab-case — .nav-bar, .user-profile-card
• CSS custom properties (variables): --kebab-case — --primary-color, --font-size-lg
• HTML data attributes: data-kebab-case — data-user-id, data-toggle-state
• BEM modifier names: kebab-case — .btn--primary-large

SQL and Databases

SQL

SQL is case-insensitive for keywords, but column names and table names have a strong community convention — though it varies slightly by database system:

• Table names: snake_case, plural — user_accounts, order_items
• Column names: snake_case — first_name, created_at, is_active
• SQL keywords: UPPERCASE by convention — SELECT, FROM, WHERE
• Stored procedure names: snake_case — get_user_by_id

Java and C#

Java

• Variables and methods: camelCase — getUserName(), isActive
• Classes and interfaces: PascalCase — UserService, IRepository
• Constants: CONSTANT_CASE — MAX_SIZE, DEFAULT_TIMEOUT
• Packages / namespaces: all lowercase — com.example.userservice

Ruby

Ruby

• Variables and methods: snake_case — user_name, get_profile
• Classes and modules: PascalCase — UserProfile
• Constants: CONSTANT_CASE or PascalCase — MAX_SIZE, AppConfig

Go

Go

Go has a unique rule: capitalisation controls visibility. An exported (public) identifier starts with a capital letter; an unexported (private) one starts lowercase. Both use camelCase or PascalCase with no underscores (except in test files and generated code):

• Exported identifiers: PascalCase — UserProfile, GetUser()
• Unexported identifiers: camelCase — userProfile, getUser()

The Quick-Reference Table: All Conventions at a Glance

camelCase vs snake_case: Which Is Actually More Readable?

This is the one naming debate that never quite ends. Both camps have strong opinions. Here is an honest assessment:

The case for camelCase

• Saves characters — no underscores between every word
• Standard in the most widely used languages (JavaScript, Java, Swift, Dart)
• Works naturally on keyboards where underscore requires Shift
• More compact — userFirstName vs user_first_name

The case for snake_case

• Research on reading speed consistently finds that underscores are slightly faster to parse for long identifiers
• Each word boundary is visually unambiguous — user_id vs userId are equally clear, but html_parser is clearer than htmlParser for a new reader
• Works cleanly in environments that are case-insensitive (like SQL and some operating systems)
• Easier for non-native English speakers to read, since the word boundaries are explicit

Common Mistakes to Avoid

Even experienced developers make these mistakes when switching between languages or contexts:

• Mixing conventions in the same file: userName in one function and user_name in another creates confusion and looks unprofessional — even if both are technically valid.
• Using camelCase in CSS: .navBar and .NavBar are almost always wrong. CSS class names should be kebab-case: .nav-bar.
• Using snake_case in JavaScript: Writing get_user_data() in JavaScript marks you immediately as someone who normally writes Python. Stick to getUserData().
• Forgetting CONSTANT_CASE for true constants: If a value never changes — an API endpoint, a timeout limit, a config value — name it in CONSTANT_CASE so other developers know not to modify it.
• Inconsistent file naming: Mixing UserProfile.js and user-settings.js in the same project makes imports harder and looks sloppy. Pick one and stick to it.
• Abbreviations in the wrong case: HTMLParser or HtmlParser? userID or userId? Most modern style guides (Google, Airbnb) recommend treating abbreviations like regular words: HtmlParser and userId.

How to Convert Between Naming Conventions Instantly

During refactors, code reviews, or when switching from one language to another, you often need to rename a batch of variables from one convention to another. Doing it manually — editing each name one at a time — is slow and error-prone.

The Developer Cases tool on Quick Case Converter converts any text between all five naming conventions instantly. Paste a list of names (one per line) and get them all converted to camelCase, PascalCase, snake_case, CONSTANT_CASE, or kebab-case in one click.

• Rename 50 Python variables to JavaScript camelCase in seconds
• Convert a list of SQL column names to the camelCase your ORM expects
• Turn plain English descriptions into any naming convention for new variable names
• Generate CSS class names in kebab-case from plain text component names

Related Free Tools

Frequently Asked Questions