← Back to UltraToolkit | All Posts

Naming Conventions in Programming: camelCase, snake_case, PascalCase, and kebab-case

A language-by-language reference for when each convention applies and why mixing them is a code quality issue.

Naming conventions in code are not arbitrary style preferences β€” they carry semantic meaning, improve readability, and signal whether code follows language idioms. Using the wrong convention is a consistent signal that reduces team confidence in code quality.

camelCase

First letter lowercase, subsequent words capitalised: userFirstName, calculateTotal. Standard for: JavaScript/TypeScript variables and functions, Java/C# method names, JSON property keys in REST APIs.

PascalCase (UpperCamelCase)

Every word capitalised: UserProfile, ShoppingCart. Standard for: class names in all OOP languages, React component names (required β€” lowercase = HTML element), TypeScript interfaces and types, C# namespaces.

snake_case

All lowercase, underscores between words: user_first_name, calculate_total. Dominant in Python (PEP 8), Ruby, database column names, environment variable names (SCREAMING_SNAKE_CASE for constants).

kebab-case

All lowercase, hyphens between words: user-profile, shopping-cart. Not a valid identifier in most languages (hyphen = minus operator). Correct domains: CSS class names, HTML attributes, URL slugs, web file names.

Converting Between Cases

When moving data across language boundaries β€” database column to Python variable to JSON key to React prop β€” converting manually introduces typos. UltraToolkit's Text Case Converter handles all eight formats simultaneously. Paste plain English, click the target case, copy the result.

camelCase vs snake_case: Choosing the Right Convention

The choice between camelCase and snake_case is not arbitrary β€” it follows language conventions that the developer community has established over decades. JavaScript and TypeScript use camelCase for variables and functions (firstName, getUserById, calculateTax), while Python uses snake_case for the same constructs (first_name, get_user_by_id, calculate_tax). Using the wrong convention in a language creates immediate friction for any developer familiar with that language's ecosystem.

The practical reason conventions matter in collaborative codebases is readability at scale. When a team of ten developers writes code using consistent naming conventions enforced by a style guide and a linter, any developer can read any file in the codebase and understand the meaning of identifiers immediately. The convention itself carries information: in TypeScript, if an identifier uses PascalCase, it is a class or interface. If it uses camelCase starting with 'is' or 'has', it is a boolean. If it uses SCREAMING_SNAKE_CASE, it is a constant. These conventions function as a second layer of type information layered on top of the type system.

When to Use Each Case Style

camelCase is the standard for: JavaScript variables and functions, TypeScript variables, functions, and method names, Java variables and methods, Go variables and functions (exported identifiers use PascalCase), C# local variables and parameters. PascalCase (UpperCamelCase) is the standard for: JavaScript and TypeScript classes and interfaces, C# public members and classes, Python classes. snake_case is the standard for: Python variables, functions, and module names, Ruby variables and methods, SQL column and table names, PostgreSQL function names.

kebab-case (hyphen-separated) is primarily used for: CSS class names and custom properties, HTML attributes that are not camelCase (data-user-id, aria-labelledby), URL paths and slugs (/blog/my-post-title), file names in web projects (my-component.tsx). Kebab-case cannot be used for variable names in most programming languages because hyphens are interpreted as the subtraction operator. Attempting to use kebab-case for a variable name results in a syntax error.

Converting Between Cases in Development Workflows

Case conversion arises in development workflows when working across system boundaries. A database schema uses snake_case column names (user_first_name). An API returns those values as camelCase JSON properties (userFirstName). A frontend component receives the camelCase JSON and displays it as Title Case in the UI (User First Name). Three different representations of the same underlying data, converted automatically at each boundary.

Most ORMs and serialisation libraries handle JSON case conversion automatically. Django REST Framework serialises Python snake_case model fields to camelCase JSON by default with the appropriate configuration. Prisma returns JavaScript-style camelCase from database snake_case columns automatically. When automatic conversion is not available, a utility function converts between cases programmatically β€” the UltraToolkit Text Case Converter performs these conversions manually for one-off needs without requiring a full development environment.

SCREAMING_SNAKE_CASE: Constants and Environment Variables

SCREAMING_SNAKE_CASE (all uppercase letters with underscores) is universally used for constants and environment variables across virtually all programming languages. In JavaScript and TypeScript, true constants β€” values that will never change during the program's execution and are known at compile time β€” use SCREAMING_SNAKE_CASE: MAX_RETRY_ATTEMPTS, API_BASE_URL, DEFAULT_TIMEOUT_MS. Environment variables follow the same convention by universal convention: DATABASE_URL, JWT_SECRET, NODE_ENV, PORT.

The visual distinctiveness of SCREAMING_SNAKE_CASE serves an important readability purpose: it immediately signals to a reader that this value is not computed, not configurable at runtime, and will be the same value every time it is referenced. If a developer sees MAX_RETRY_ATTEMPTS in a function, they know to look at the constant definition to understand its value β€” they do not need to trace through the call stack to find where it was set. This immediate disambiguation is the practical benefit that justifies the typographical emphasis.

Enforcing Conventions with Linters

ESLint's @typescript-eslint/naming-convention rule enforces naming conventions in TypeScript projects with configuration for each identifier type. Set camelCase for variables, functions, and parameters. Set PascalCase for classes, interfaces, and type aliases. Set UPPER_CASE for const enum members. Configure the rule once in .eslintrc and it flags violations in the IDE in real time and in CI checks. The rule supports prefixes and suffixes β€” you can require boolean variables to start with 'is', 'has', 'should', or 'can' to make boolean semantics explicit.

For Python, flake8 with the pep8-naming plugin enforces PEP 8 naming conventions. For CSS, stylelint enforces BEM or any custom naming pattern on class names using regex-based rules. For teams adopting consistent naming conventions in an existing codebase, automated renaming tools handle the mechanical work β€” TypeScript's rename symbol (F2 in VS Code) renames across all usages safely, and jscodeshift applies systematic renames via AST transformation for large-scale migrations.

Convert variable names between any naming convention instantly with the Text Case Converter. camelCase, snake_case, PascalCase, kebab-case and more.

Try Naming Conventions in Programming for free

All 14 utilities are free, instant, and require no account or installation.

Open Tool β†’    All Free Tools
← Back to UltraToolkit All Posts β†’