A Practical Guide to Naming Conventions in Code

userName, user_name, UserName, user-name, USER_NAME — five different ways to write the same two words, and every one of them is the expected, idiomatic choice somewhere. Naming conventions aren't arbitrary style preferences; each one exists because a specific language, format, or context settled on it, often for real technical reasons.

camelCase

userName, isLoggedIn, calculateTotalPrice

The first word is lowercase, every subsequent word starts with a capital letter, no separators. This is the standard convention for variables and function names in JavaScript, Java, and C#, and it's also the dominant convention for JSON field names in most modern APIs, since JSON grew up alongside JavaScript.

PascalCase

UserAccount, HttpRequestHandler, OrderSummary

Identical to camelCase except the very first word is also capitalized. This is the standard for class and type names across most languages that use camelCase for variables — JavaScript, Java, C#, and TypeScript all use PascalCase specifically to name classes, interfaces, and components, which creates a useful visual distinction: seeing UserAccount tells you at a glance that it's a type, not a variable holding a value.

snake_case

user_name, is_logged_in, calculate_total_price

All lowercase, words separated by underscores. This is the standard convention in Python and Ruby, and it's also extremely common for database column names (most SQL databases are case-insensitive by default, which makes camelCase risky to rely on, since some database systems will silently fold it to lowercase).

kebab-case

user-name, main-navigation, btn-primary

Lowercase words separated by hyphens. You'll see this constantly in URLs and slugs (/blog/my-post-title), CSS class names (.btn-primary), and HTML attributes. It's not used for variable names in most programming languages, because a hyphen is also the subtraction operator, and user-name would be parsed as "user minus name" rather than as a single identifier.

CONSTANT_CASE (or SCREAMING_SNAKE_CASE)

MAX_RETRY_COUNT, API_BASE_URL, DEFAULT_TIMEOUT_MS

All uppercase, words separated by underscores. The near-universal convention for constants across most programming languages, and for environment variable names in .env files and shell scripts. The visual "shouting" is doing real work here — it signals at a glance "this value never changes," which is a genuinely useful distinction when skimming code.

Why does this matter enough to have a convention at all?

Consistency inside a single codebase matters more than which specific convention you pick. A codebase that mixes userName, user_name, and UserName for the same concept in different places forces every reader to constantly context-switch and remember which style applies where. Following the dominant convention of whatever language or format you're working in also means new contributors, linters, and tooling all behave the way they expect to, with no friction.

A practical cheat sheet

The trickiest case: acronyms

How should XMLHttpRequest or a variable holding a URL be cased? Conventions genuinely differ here even within a single language community. Some style guides treat an acronym as a single word (XmlHttpRequest, Url), others keep it fully capitalized (XMLHttpRequest, URL). Neither is objectively correct; the only real mistake is inconsistency — using UrlParser in one file and URLParser in another for the same kind of concept.

Converting between conventions

When you're porting a field name across a language boundary — say, a JSON API using camelCase feeding into a Python backend that wants snake_case internally, or a UI label that needs to become a URL slug — the conversion is mechanical once you know the rule: split the identifier into individual words (which requires detecting case boundaries as well as existing separators), then rejoin them using the target convention's rules.

Frequently Asked Questions