Programming Case Conventions: The Complete Guide

Every programmer faces it constantly: you need to name a variable, a function, a class, a file, a CSS class, a constant — and each of those has a conventional naming style that experienced developers follow without thinking. camelCase, PascalCase, snake_case, kebab-case, SCREAMING_SNAKE_CASE: this is the vocabulary of programming case conventions. This guide brings them all together — what each is, where it belongs, and how to choose — so the whole landscape finally makes sense.

It is written for developers and students who want a clear, complete reference for naming conventions across languages and contexts.

Why Case Conventions Exist

Before the specifics, it is worth understanding why programming has so many naming styles in the first place, because the reason makes the whole topic coherent. Identifiers in code cannot contain spaces, yet most meaningful names are made of multiple words. Case conventions are the various solutions to one problem: how to join multiple words into a single readable identifier. Some solutions use capitalisation to mark word boundaries (camelCase, PascalCase); others use a separator character (snake_case with underscores, kebab-case with hyphens). Each emerged in particular languages and communities and became standard there.

The deeper purpose, though, is communication. Over time, the different styles came to signal what kind of thing an identifier represents — a variable, a class, a constant, a URL — so that the case itself carries information a reader can absorb at a glance. This is why conventions matter even though a program runs regardless of the style you use: code is read far more than written, and consistent, conventional naming lets readers understand it faster. The many case styles are not arbitrary clutter; they are a shared visual language, and learning to read and use them fluently is part of becoming a fluent programmer.

In short: The main programming case conventions are camelCase (variables, functions), PascalCase (classes, types, components), snake_case (Python identifiers, database columns), SCREAMING_SNAKE_CASE (constants) and kebab-case (URLs, CSS, file names). Each signals a kind of identifier; the key is to follow your language's conventions consistently.

The Main Conventions at a Glance

These five cover the vast majority of naming in everyday programming. There are others — such as Train-Case (capitalised words with hyphens) seen in some headers, or dot.case in certain configuration keys — but the five above are the workhorses you will use and read constantly. Notice how they split into the two families: case-based (camelCase, PascalCase) and separator-based (snake_case, kebab-case), with SCREAMING_SNAKE_CASE being the all-caps separator form reserved for constants.

Choosing by Context, Not Preference

The single most important principle is that case conventions are chosen by context — the language, the kind of identifier, and the surrounding ecosystem — not by personal preference. The right style for a given name is whatever its context conventionally expects, and that varies. The same concept might be userName as a JavaScript variable, user_name as a Python variable or database column, UserName as a class, and user-name as a CSS class or URL slug. None of these is "more correct" in the abstract; each is correct in its context. Trying to impose one favourite style everywhere fights the conventions and produces code that looks wrong to everyone familiar with the ecosystem.

This is why the practical advice is always "follow the conventions of your language and project." Each major language has a style guide — explicit or community-established — that specifies which case to use for which kind of identifier, and the strong recommendation is to learn and follow it. When you write Python, use snake_case for variables and functions; when you write JavaScript, use camelCase for them and PascalCase for classes and components; when you write CSS or create URLs, use kebab-case; and use SCREAMING_SNAKE_CASE for constants almost everywhere. Letting context dictate the case, rather than personal habit, is what makes your code fit naturally into its environment and read clearly to others working there.

Consistency Is the Real Goal

If there is one rule that matters more than the specifics, it is consistency. The exact convention a project uses is far less important than the fact that it is applied uniformly. A codebase that consistently uses one set of conventions is readable and professional even if you might personally have chosen differently; a codebase that mixes conventions arbitrarily is hard to read and feels disorganised no matter how "correct" each individual name might be in isolation. Readers build expectations from the patterns they see, and inconsistency constantly violates those expectations, slowing comprehension and eroding trust in the code.

In practice, consistency is maintained through shared conventions and tooling. Teams adopt a style guide so everyone names things the same way, and they often use automated linters and formatters that flag or fix naming that deviates from the agreed conventions, taking the burden off individual memory. The goal is that naming becomes predictable: a reader anywhere in the codebase can rely on the same rules, so the case of an identifier is always a trustworthy signal of its kind. Whether you are working solo or on a large team, deciding on your conventions and applying them everywhere — with tooling to help — is what turns case styles from a source of friction into the quiet, dependable aid to readability they are meant to be.

The Two Families and Their Logic

A helpful way to organise all these conventions in your mind is to see them as two families that solve the word-joining problem in opposite ways. The case-based family — camelCase and PascalCase — uses capitalisation to mark where one word ends and the next begins, packing the words together with no separators. The separator-based family — snake_case and kebab-case, plus the all-caps SCREAMING_SNAKE_CASE — uses an explicit character, an underscore or a hyphen, to divide the words while keeping them lowercase. Almost every convention you will meet is a member of one family or the other, and seeing them this way reduces a seemingly long list to a simple two-by-two grid: capitalise or separate, and within each, a variation for a special role.

This framing also explains why certain conventions cluster in certain places. The separator-based styles dominate where lowercase readability and safe separators matter — Python's readable identifiers, database columns, URLs and CSS — and they split by separator according to technical constraints, with underscores indoors (where hyphens would mean subtraction) and hyphens on the web (where they are URL-safe and SEO-friendly). The case-based styles dominate where compactness and the type-versus-value distinction matter — the variables, functions, classes and components of languages like JavaScript, Java and C#. The all-caps form sits across both as the universal marker for constants. Once you internalise this map of families and their natural habitats, you no longer memorise rules case by case; you reason from the logic, which is what lets experienced developers name things correctly even in an unfamiliar language.

Converting Between Conventions

A practical reality of modern development is that data and identifiers frequently cross boundaries between systems that use different conventions, so converting between cases is a routine task. An API might return data with snake_case keys that a JavaScript front-end wants to use as camelCase; a database's snake_case columns map to an application's camelCase or PascalCase models; a content title needs to become a kebab-case URL slug; a configuration value moves between formats with different conventions. In each case, something must translate the identifier from one style to another, and doing so by hand is slow and error-prone, especially across many names.

This is exactly the kind of mechanical transformation a tool should handle, and many frameworks and libraries include automatic case conversion at these boundaries precisely because it is so common. For one-off conversions, reformatting a list of names during a refactor, or generating slugs from titles, a case converter does the job instantly and reliably. The broader point is that fluency with case conventions includes knowing not just which style belongs where, but how to move smoothly between them when systems with different conventions meet — which they constantly do. Treating conversion as a normal, tool-assisted part of the workflow, rather than tedious manual editing, keeps your identifiers correct in every context they pass through.

Try Our Free Case Converter

Converting identifiers between these conventions — when refactoring, migrating between languages, or generating slugs — is exactly what a tool should handle. Our Case Converter converts text between all the major cases instantly.

• ✅ Convert between camelCase, PascalCase, snake_case, kebab-case, UPPER_CASE and more
• ✅ Reformat identifiers quickly when refactoring or migrating
• ✅ Runs in your browser — your text stays private

👉 Convert between any case now →

Conventions Across Languages

Seeing how the conventions play out across ecosystems ties everything together. In JavaScript and TypeScript, variables and functions are camelCase, classes and React components are PascalCase, constants are often SCREAMING_SNAKE_CASE, and CSS classes and file names trend toward kebab-case. In Python, variables, functions and methods are snake_case, classes are PascalCase, and constants are SCREAMING_SNAKE_CASE. In Java and C#, classes and types are PascalCase, with methods and variables following each language's convention. In web development generally, URLs and CSS use kebab-case regardless of the backend language. The pattern across all of them is consistent in spirit: PascalCase marks types, a lower style marks values and functions, all-caps marks constants, and hyphenated lowercase marks web identifiers. Once you internalise that mapping, you can move between languages and instantly know how to name things in each.

Common Mistakes

1. Imposing one favourite style everywhere instead of following each context's convention.
2. Mixing conventions inconsistently within a codebase, which undermines readability.
3. Using the wrong case for a kind of identifier — e.g. camelCase classes or PascalCase variables.
4. Using underscores in URLs where hyphens (kebab-case) are expected.
5. Ignoring the language's style guide, producing code that looks unfamiliar to its community.

Best Practices

• Learn and follow your language's style guide for which case to use where.
• Let context choose the case — variable, class, constant, URL — not personal preference.
• Prioritise consistency across the whole codebase above all.
• Use linters and formatters to enforce naming conventions automatically.
• Use a case converter when reformatting or migrating identifiers between styles.

Frequently Asked Questions

What are the main programming case conventions?

The main ones are camelCase (variables, functions), PascalCase (classes, types, components), snake_case (Python identifiers, database columns), SCREAMING_SNAKE_CASE (constants) and kebab-case (URLs, CSS classes, file names).

How do I choose which case to use?

Choose by context, not preference: follow the convention your language and ecosystem expect for that kind of identifier. The same concept may be camelCase in JavaScript, snake_case in Python, and kebab-case in a URL.

Why are there so many case conventions?

Because identifiers cannot contain spaces, so different communities solved the problem of joining words differently — some with capitalisation, some with separators. Over time each style came to signal a particular kind of identifier.

Which case is used for constants?

SCREAMING_SNAKE_CASE — all capitals with underscores, like MAX_SIZE — is the near-universal convention for constants across most programming languages.

Does the choice of case affect how code runs?

Generally no; the program runs regardless of style (with rare exceptions like React requiring PascalCase components). Conventions exist for readability and communication, not for the compiler.

What matters most with case conventions?

Consistency. Applying one set of conventions uniformly across a codebase matters more than the specific choices, because consistency is what makes naming a reliable, readable signal.

Conclusion

Programming case conventions are a shared visual language: camelCase for variables and functions, PascalCase for classes and types, snake_case for Python and databases, SCREAMING_SNAKE_CASE for constants, and kebab-case for URLs, CSS and file names. They exist because identifiers cannot contain spaces, and they endure because the case of a name signals what kind of thing it is, letting developers read code faster. The guiding principles are simple: choose the case by context rather than preference, follow your language's conventions, and above all stay consistent across the codebase, using linters and a case converter to help. Master this vocabulary and you will name things correctly in any language — and read others' code with ease.

👉 Convert between all the cases with our free tool →

Related Resources

• Case Converter — convert between every major case
• camelCase vs PascalCase — the capital-letter styles
• snake_case Explained — the underscore style
• kebab-case Explained — the hyphen style
• Title Case vs Sentence Case — the editorial cases