Every programmer has to name things: variables, functions, classes, files, database columns, API endpoints. The way you name these things — the "naming convention" you follow — affects readability, maintainability, and how well your code integrates with the tools and frameworks in your ecosystem.

This guide covers every major naming convention, when to use each, and how different programming languages and contexts approach this fundamental question.

Why Naming Conventions Matter

Imagine reading code where variables are named CustomerFirstName, customer_last_name, customerAge, and CUSTOMER-ID — four different naming styles for related concepts. This inconsistency creates unnecessary cognitive load. Your brain has to process not just what the variable means but also why it's named differently from its siblings.

Consistent naming conventions solve this by creating predictability. When you've established that all functions use camelCase and all classes use PascalCase, you can instantly tell what type of thing you're looking at just from the name format.

The Major Naming Conventions

camelCase

camelCase starts with a lowercase letter, and each subsequent word starts with an uppercase letter. The name comes from the way the uppercase letters create "humps" like a camel's back.

Examples: firstName, getUserById, totalPriceWithTax, isUserLoggedIn

Used for:

  • Variables and function names in JavaScript, Java, C#, Go, Dart
  • JSON property names (convention, not a strict standard)
  • React component state variables

PascalCase (UpperCamelCase)

PascalCase is like camelCase but the first letter is also uppercase. Every word starts with a capital letter. Also called "UpperCamelCase" or "StudlyCase."

Examples: UserAccount, GetUserById, ShoppingCart, HttpResponseMessage

Used for:

  • Class names in virtually all languages (Java, C#, Python, JavaScript)
  • Component names in React and Vue
  • Interface names in TypeScript and C#
  • Methods in C# and some Ruby conventions
  • Public methods in Go (exported identifiers)

snake_case

snake_case uses all lowercase letters with words separated by underscores. The name refers to the horizontal appearance, like a snake lying flat.

Examples: first_name, get_user_by_id, total_price_with_tax, user_id

Used for:

  • Variables and functions in Python (the official style guide, PEP 8, mandates snake_case)
  • Variables and functions in Ruby
  • Database column names (nearly universal convention)
  • File names in Linux/Unix systems
  • Variables in PHP (common convention)
  • Rust uses snake_case for variables and functions

SCREAMING_SNAKE_CASE (UPPER_SNAKE_CASE)

Like snake_case but all capitals. This is conventionally used for constants — values that never change after being set.

Examples: MAX_RETRY_COUNT, API_BASE_URL, DEFAULT_TIMEOUT_MS

Used for:

  • Constants in Java, JavaScript/TypeScript, Python, C/C++
  • Environment variable names (almost universally)
  • Enum values in many languages

kebab-case (hyphen-case)

kebab-case uses all lowercase letters with words separated by hyphens. The name comes from the image of words skewered together like kebab on a stick.

Examples: first-name, user-profile-settings, background-color

Used for:

  • CSS class names and property names (the standard in CSS)
  • HTML attribute names
  • URL slugs and file names in web projects
  • Vue component names in templates
  • NPM package names (react-router-dom, lodash-es)

Note: kebab-case cannot be used as variable names in most programming languages because the hyphen is the subtraction operator. let first-name = "John" is not valid JavaScript — it looks like subtraction.

dot.case

Words separated by dots. Less common for variable naming but appears in specific contexts.

Examples: system.user.id, app.config.database

Used for:

  • Configuration keys (Spring Boot, .env files)
  • Namespace identifiers in some languages
  • Log categories

Language-by-Language Overview

| Language | Variables/Functions | Classes | Constants | Files | |---|---|---|---|---| | JavaScript/TypeScript | camelCase | PascalCase | UPPER_SNAKE | kebab-case | | Python | snake_case | PascalCase | UPPER_SNAKE | snake_case | | Java | camelCase | PascalCase | UPPER_SNAKE | PascalCase | | C# | camelCase | PascalCase | PascalCase | PascalCase | | Ruby | snake_case | PascalCase | UPPER_SNAKE | snake_case | | Go | camelCase | PascalCase | PascalCase | snake_case | | Rust | snake_case | PascalCase | UPPER_SNAKE | snake_case | | PHP | camelCase | PascalCase | UPPER_SNAKE | snake_case | | Swift | camelCase | PascalCase | camelCase | PascalCase |

Special Conventions

Hungarian Notation

Hungarian notation prefixes variable names with type information: strName (string), intAge (integer), bIsActive (boolean). This was common in older C and Win32 code.

Modern IDEs make Hungarian notation largely unnecessary — you can hover over any variable to see its type. Most style guides today discourage it. However, you might still see it in legacy code or in specific domains like Microsoft Win32 API development.

Leading Underscores

In many languages, a leading underscore signals that a variable or method is "private" or "internal":

  • _privateMethod() — Python convention for "private" (not truly enforced)
  • __name — Python name mangling for true private attributes
  • _internalVariable — common in JavaScript before private class fields (#field) were available

Trailing Underscores

A trailing underscore avoids clashes with reserved keywords: class_, type_, id_. This is occasionally used in Python when the ideal variable name is a reserved word.

Interface Prefixes

In C# and TypeScript, interfaces are often prefixed with I:

  • IUserRepository
  • IDisposable

This is strongly conventional in C# and mixed in TypeScript — the TypeScript team itself recommends against the I prefix in their own code.

Naming Things Well: Beyond Convention

Following the right case style is the floor, not the ceiling, of good naming. Here are higher-level principles:

Be Descriptive, Not Clever

getUserAccountBalance() beats getUAB() and fetch(). Abbreviations save characters while typing but cost seconds of confusion when reading. Code is read far more often than it is written.

Use the Problem Domain's Vocabulary

If you're building an e-commerce system, use terms from e-commerce: Order, LineItem, SKU, fulfillmentStatus. This aligns the code with how stakeholders and domain experts talk about the system.

Boolean Variables Should Be Yes/No Questions

Prefix boolean variables with is, has, can, or should:

  • isActive, hasPermission, canEdit, shouldRedirect

This makes conditionals read naturally: if (isActive) vs. if (active).

Function Names Should Be Verbs

Functions do things, so they should start with a verb: get, set, create, update, delete, validate, calculate, render, handle.

Avoid Meaningless Names

Names like data, info, temp, obj, thing, and single-letter variables (outside of loop counters and mathematical contexts) give readers no useful information. What kind of data? Information about what?

Converting Between Cases

When you need to switch from one naming convention to another — say, converting a JSON API response (camelCase) to a Python variable (snake_case) — it's helpful to have a reliable tool. The Case Converter tool on this site handles these transformations instantly, supporting camelCase, PascalCase, snake_case, SCREAMING_SNAKE_CASE, and kebab-case.

Naming conventions are one of those things that seem trivial until you work on a large codebase with an inconsistent approach. The payoff for consistency is enormous: faster code reviews, clearer communication between team members, and code that documents itself.