Naming Conventions in Programming: The Complete Guide to Text Case

Naming conventions are not preferences — in many contexts they are enforced by linters, compilers, or frameworks. In every other context, following them signals that you understand the ecosystem you are working in.

camelCase

Starts lowercase, capitalises each subsequent word: myVariableName, getUserData. The dominant convention for variables and functions in JavaScript, Java, C#, Swift, and Kotlin.

PascalCase

Capitalises every word including the first: UserProfile, InvoiceGenerator. Convention for class names in Java, C#, JavaScript, TypeScript, and Python. In React, all component names must be PascalCase — lowercase names are interpreted as DOM elements.

snake_case

Lowercase with underscores: user_first_name, calculate_total. Required by Python (PEP 8) for variables and functions. Standard for SQL table and column names in most databases. Highly readable because word boundaries are unambiguous.

kebab-case

Lowercase with hyphens: user-profile, main-content. Convention for CSS class names, HTML IDs, URL slugs, and file names. Cannot be used for JavaScript variable names — hyphens are parsed as subtraction operators.

Converting Instantly

The Text Case Converter handles all eight conventions with one click. Paste any text — a database column name, an English description, a heading — and convert to any format your codebase requires.

Why Naming Conventions Actually Matter

Naming conventions are not aesthetic preferences — they are communication protocols between developers. When a developer reads getUserById, they immediately know it is a function (verb phrase), returns a single item (not a list), and accepts an identifier parameter. When they read user_id, they know they are reading Python or a database column. When they read USER_MAX_RETRIES, they know it is a constant. These conventions carry semantic information that helps developers read unfamiliar code faster.

Violations of established conventions in a codebase create cognitive friction. A Python function named getUserById (camelCase) signals that the code was written by someone unfamiliar with Python conventions, or copied from JavaScript without adaptation. Either way, it raises questions about code quality and creates a maintenance burden as future developers encounter inconsistencies. Consistent naming conventions, applied automatically through team agreements and enforced by linters, eliminate this friction entirely.

JavaScript and TypeScript Conventions in Depth

Variables declared with const or let: camelCase. Start with a lowercase letter, subsequent words capitalised with no spaces or underscores. Examples: userName, totalPrice, isLoggedIn, httpClient, apiResponse. Functions: same camelCase convention as variables. Function names should typically be verb phrases describing what the function does: calculateTotal, validateEmail, fetchUserById, handleSubmit.

Classes and constructors: PascalCase (also called UpperCamelCase). Every word capitalised, no separators. Examples: UserAccount, HttpClient, ApiResponse, DatabaseConnection. This convention allows JavaScript developers to distinguish class references from function or variable references at a glance. Interfaces and type aliases in TypeScript follow the same PascalCase convention as classes.

Constants that represent fixed values known at compile time: SCREAMING_SNAKE_CASE. All uppercase with underscores separating words. Examples: MAX_RETRY_COUNT, API_BASE_URL, DEFAULT_TIMEOUT_MS, HTTP_STATUS_OK. This visual distinction immediately communicates to a reader that a value will never change during runtime. Note that const in JavaScript does not mean constant — it means the binding cannot be reassigned. A const object can still have its properties mutated. SCREAMING_SNAKE_CASE is for truly immutable values.

Python-Specific Conventions

Python's naming conventions are codified in PEP 8, the official Python style guide. Variables and functions: snake_case exclusively. Words separated by underscores, all lowercase. Python linters (flake8, pylint) and formatters (black) enforce this automatically. Examples: user_account, calculate_total, fetch_user_by_id, http_client. Classes: PascalCase, same as JavaScript/TypeScript. This is a deliberate exception to snake_case for the one context where the distinction between a class and a regular function or variable matters most.

Module names: short, lowercase, no underscores where possible. Python modules are imported frequently and module names appear in import statements throughout codebases. utils, models, helpers, validators, services are common module names. Package names (directories containing __init__.py): same convention as module names. Private attributes and methods: single leading underscore (_private_method). This is a naming convention, not an access modifier — Python does not enforce private access. Name mangling for class-private attributes: double leading underscore (__name_mangled).

CSS and HTML Naming Systems

CSS class names: kebab-case universally. All words lowercase, separated by hyphens. Examples: nav-bar, hero-section, btn-primary, card-header, modal-overlay. This matches the existing syntax of HTML attributes and CSS property names (background-color, font-size), creating visual consistency throughout web codebases. CSS IDs: also kebab-case. IDs are used sparingly in CSS (prefer classes for styling) but when used, follow the same convention: main-content, user-profile, sidebar-nav.

BEM (Block Element Modifier) is a naming methodology that encodes component structure into CSS class names. Block: a standalone component (.card, .nav, .btn). Element: a part of the block that has no standalone meaning (.card__header, .card__body, .nav__item). Modifier: a variation or state of a block or element (.btn--primary, .btn--large, .card__header--highlighted). BEM class names look verbose but eliminate naming conflicts in large codebases and communicate component structure without requiring developers to understand the HTML structure.

Database and SQL Naming Conventions

SQL is case-insensitive for keywords and identifiers in most databases, but conventions vary by team. The most common convention: table names in plural snake_case (users, order_items, product_categories), column names in snake_case (first_name, created_at, is_active, total_amount). Primary key columns: id or tablename_id (user_id in the users table). Foreign key columns: referenced_table_id (user_id in the orders table references users.id). Boolean columns: is_ prefix (is_active, is_published, is_verified).

Index naming: idx_tablename_columnname or ix_tablename_columnname (idx_users_email, idx_orders_user_id). Unique constraint naming: uq_tablename_columnname (uq_users_email). Foreign key constraint naming: fk_tablename_referenced_tablename (fk_orders_users). These naming conventions make schema inspection and debugging significantly faster — a developer who needs to understand an index or constraint can immediately identify its purpose and the tables it involves from the name alone.

Automated enforcement of naming conventions eliminates the cognitive overhead of checking every variable name manually. ESLint's @typescript-eslint/naming-convention rule enforces naming conventions across TypeScript codebases with granular control — different rules for different declaration types (variable, function, class, interface, enum). Configure it in your ESLint configuration once and the rule flags violations on every save in your IDE and in CI pipeline checks. For Python, the pylint naming-convention checks enforce PEP 8 naming automatically. For CSS, stylelint with the stylelint-selector-bem-pattern plugin enforces BEM naming conventions on CSS class names.

For teams migrating existing codebases to consistent naming conventions, automated renaming tools handle the mechanical work. TypeScript's rename symbol feature (F2 in VS Code) safely renames identifiers across all usages in the project, including string references that TypeScript can track. For large-scale renames across many files, codemod tools like jscodeshift apply systematic transformations using AST manipulation rather than text replacement, ensuring correctness even for complex refactoring scenarios.