Code Naming Conventions: Why camelCase, snake_case, and kebab-case Each Exist

Naming conventions in code aren't just style — they're a form of communication

A variable named x tells you nothing. A variable named monthlyInterestRate tells you its purpose, its domain, and its unit. The difference between these isn't pedantry — it's the difference between code that requires context to understand and code that communicates its intent.

Case conventions are the grammar of naming: the rules that determine how multi-word identifiers are formatted. Different programming communities settled on different conventions — and understanding why helps you apply them correctly rather than mechanically.

Why different languages have different conventions

Case conventions didn't arise from arbitrary decisions. They reflect the design philosophy and community culture of each language.

Python's snake_case originates in readability culture. Python's PEP 8 style guide (2001) explicitly chose snake_case for variables and functions because it closely mirrors written English — calculate_monthly_payment reads almost like a sentence. Python's emphasis on readability as a first-class concern pushed the community toward the most human-readable format.

JavaScript's camelCase inherited from Java and C, where object-oriented programming encouraged identifiers that read like noun phrases. calculateMonthlyPayment mimics English noun phrases without spaces. The web's JavaScript grew alongside Java-influenced tooling, cementing the convention.

CSS's kebab-case (background-color, font-size) was partly an accident of early CSS parser design — hyphens were the first multi-word separator implemented, and the convention stuck. It also aligns with HTML attribute conventions.

Database snake_case reflects SQL's origins in IBM's structured English Query Language design — SQL is case-insensitive, identifiers often appear mixed with reserved words, and snake_case provides clear word boundaries without ambiguity.

The full case reference

Language-specific deep dive

Python (PEP 8)

# Variables and functions: snake_case
monthly_interest_rate = 0.075
def calculate_emi(principal, rate, tenure):
    pass

# Classes: PascalCase
class LoanCalculator:
    pass

# Constants: SCREAMING_SNAKE_CASE
MAX_LOAN_AMOUNT = 10_000_000
DEFAULT_CURRENCY = "GBP"

# Private attributes: leading underscore
self._internal_rate = 0.05

JavaScript/TypeScript

// Variables and functions: camelCase
const monthlyInterestRate = 0.075;
function calculateEmi(principal, rate, tenure) {}

// Classes and constructors: PascalCase
class LoanCalculator {}

// Constants: SCREAMING_SNAKE or camelCase (community split)
const MAX_LOAN_AMOUNT = 10_000_000;  // common convention
const defaultCurrency = 'GBP';       // also acceptable

// TypeScript interfaces: often PascalCase with I prefix (debated)
interface ILoanDetails {}  // Microsoft convention
interface LoanDetails {}   // increasingly preferred without I

Database (SQL)

-- Table names: snake_case, usually plural
CREATE TABLE loan_applications (
    application_id    SERIAL PRIMARY KEY,
    applicant_name    VARCHAR(255),
    loan_amount       DECIMAL(12, 2),
    monthly_payment   DECIMAL(10, 2),
    created_at        TIMESTAMP
);

CSS

/* Classes: kebab-case */
.primary-button {}
.loan-calculator {}
.monthly-payment-display {}

/* Custom properties: kebab-case */
:root {
  --primary-color: #3A86FF;
  --font-size-base: 16px;
}

Consistency across boundaries: the real challenge

The practical difficulty isn't following conventions within one language — it's maintaining appropriate conventions as data crosses language boundaries.

A database column monthly_payment (snake_case) becomes monthlyPayment (camelCase) in a JavaScript API response and monthly_payment again in Python backend code. This serialisation/deserialisation happens automatically in many frameworks but requires explicit mapping in others.

Common bridging patterns:

# Python: map database snake_case to API camelCase
from pydantic import BaseModel

class LoanDetails(BaseModel):
    monthly_payment: float
    
    class Config:
        alias_generator = lambda field: ''.join(
            word.capitalize() if i else word
            for i, word in enumerate(field.split('_'))
        )
# Produces: { "monthlyPayment": 1250.00 }

// JavaScript: convert incoming snake_case API response to camelCase
const toCamel = (obj) => Object.fromEntries(
  Object.entries(obj).map(([k, v]) => [
    k.replace(/_([a-z])/g, (_, c) => c.toUpperCase()), v
  ])
);

The case for consistency over convention

Within a codebase, consistency matters more than following any specific convention. A Python project that consistently uses camelCase throughout is easier to navigate than one that mixes snake_case and camelCase across files.

The conventions exist because consistent naming within a community enables tooling (linters, formatters, documentation generators) to work across a shared codebase. They also create predictability — a developer familiar with Python conventions can read any well-written Python code with less mental overhead.

Using the Case Converter for development workflows

The case converter at sadiqbd.com is most useful when crossing naming conventions:

• Database column names → JavaScript API field names (snake_case → camelCase)
• Design specifications → CSS class names (mixed case → kebab-case)
• Variable names → URL slugs (camelCase or PascalCase → kebab-case)
• Config keys → environment variable names (camelCase → SCREAMING_SNAKE)

Frequently Asked Questions

Is there a performance difference between case styles? No — case formatting has no runtime performance implications. The source code is compiled or interpreted regardless of identifier format.

What about GraphQL — does it have its own conventions? GraphQL schema conventions align with JavaScript: types in PascalCase, fields and arguments in camelCase. This makes GraphQL schemas feel natural to JavaScript developers.

Does ESLint or Pylint enforce naming conventions? Yes — both support configurable naming convention rules. @typescript-eslint/naming-convention for TypeScript, pep8 and pylint for Python. These can be configured to enforce camelCase, PascalCase, and snake_case in the right contexts.

Is the Case Converter free? Yes — completely free, no sign-up required.

Case conventions are one of those things that feel arbitrary until you understand the reasoning behind them — then they become a natural part of writing code that communicates its intent clearly.

Try the Case Converter free at sadiqbd.com — convert any text between camelCase, PascalCase, snake_case, kebab-case, and more instantly.