When to Use camelCase, snake_case, and kebab-case

Naming conventions might seem like a minor detail, but consistent casing makes code more readable and maintainable. Different languages and contexts have established conventions — here's when to use each.

camelCase

myVariableName, getUserData, isAuthenticated

The first word is lowercase, subsequent words are capitalized with no separators. Called "camelCase" because the capital letters look like humps.

Use for:

• JavaScript/TypeScript variables and functions
• Java methods and variables
• JSON property names (common convention)
• CSS-in-JS property names

PascalCase (UpperCamelCase)

MyClassName, UserProfile, HttpRequest

Like camelCase, but the first letter is also capitalized. Named after the Pascal programming language where it was widely used.

Use for:

• Class names in most languages
• React component names (required)
• TypeScript interfaces and types
• C# everything (classes, methods, properties)
• Enum values in some languages

snake_case

user_name, calculate_total, is_valid

In snake_case, words are separated by underscores with all letters lowercase. This convention is common in Python, Ruby, and SQL environments. Snake_case improves readability in languages where uppercase letters might be reserved for constants or other specific uses. It's also used in configuration files, environment variables, and database schema names. While similar to camelCase in structure, the underscores make it easier to parse in certain contexts like shell scripting or when working with APIs that prioritize consistency over brevity.

SCREAMING_SNAKE_CASE

MAX_VALUE, API_KEY, DATABASE_URL

All uppercase with underscores. The name comes from the appearance of "screaming" (all caps) text.

Use for:

• Constants in most languages
• Environment variables
• Preprocessor macros in C/C++

kebab-case: For URLs, CSS Classes, and Config Keys

kebab-case uses hyphens to separate words (e.g., my-variable-name, user-profile-card, data-fetch-mode). It’s the standard convention in contexts where spaces or underscores are problematic or discouraged. In front-end development, kebab-case is the required format for HTML attribute names, CSS class names (especially in frameworks like Tailwind or Vue), and URL slugs (e.g., /guides/case-conventions-programming). It’s also common in configuration files like YAML, TOML, and JSON config keys where hyphens avoid parsing ambiguity—though JSON property names technically allow any string, kebab-case improves readability and avoids confusion with operators. Note that in many programming languages (e.g., JavaScript, Python), kebab-case cannot be used for identifiers (variable/function names) because hyphens are interpreted as minus signs, so it’s primarily reserved for markup, styling, and system-level naming.

When to Break the Rules—and How to Stay Consistent

While following language-specific conventions is best practice, real-world projects often involve mixed standards—especially when integrating legacy code, third-party APIs, or cross-team libraries. In such cases, consistency within your codebase matters more than strict adherence to a single style. Always check your project’s style guide (e.g., Airbnb, Google, or Standard JS) before writing new code. For new projects, consider adopting a linter (like ESLint or Stylelint) with auto-fix rules to enforce casing standards automatically. When contributing to open source, mirror the existing style of the repository. If you’re building a public API, document your naming convention clearly so consumers know whether to expect camelCase in JSON responses or snake_case in database fields. Ultimately, readability and predictability should guide your choices—especially when onboarding new developers.

Common Pitfalls and How to Avoid Them

Misapplied casing is a frequent source of bugs and confusion. For example, using kebab-case for JSON keys (e.g., 'user-name') can cause runtime errors in JavaScript unless accessed via bracket notation (data['user-name']). Similarly, mixing snake_case and camelCase in the same project (e.g., backend Python using snake_case with a frontend React app expecting camelCase) requires extra mapping logic and increases cognitive load. Another trap is overusing PascalCase in JavaScript modules—only class-like constructs, types, and React components should use it; regular functions and variables should stick to camelCase. To avoid these issues, establish a naming convention early, codify it in your documentation, and use tooling (like TypeScript interfaces or JSON schema validators) to catch mismatches. When in doubt, ask: 'What would the language’s official style guide recommend?'

Accessibility Considerations in Naming Conventions

Proper case conventions directly impact accessibility in web development. Screen readers and assistive technologies rely on consistent naming patterns to interpret code structure. For instance, kebab-case in ARIA attributes (aria-expanded="true") ensures predictable parsing. In JavaScript frameworks, using camelCase for accessibility-related functions (isAccessible(), validateFocus()) improves code readability for developers working on accessible interfaces. Maintaining clear naming conventions across your codebase reduces cognitive load, making it easier to identify and debug accessibility issues during development.

Quick Reference by Language

The Golden Rule

Consistency matters more than any specific convention. If you join a project using camelCase for everything, use camelCase. Match the existing codebase. For new projects, follow your language's community conventions.