When you move between programming languages, the naming conventions are one of the small frictions that slows you down. You finish a Python project and start a JavaScript project, and suddenly your fingers want to type user_name when they should be typing userName. It takes a few days to recalibrate.
Here's a side-by-side reference for the 20 languages most developers encounter, with the why behind each convention. If you only ever work in one language, this is for orientation when you read others' code. If you work in many, it's a cheat sheet.
The convention table
For each language, the table shows the dominant convention for variables, functions/methods, classes, constants, and files. "PascalCase" means the first letter is also capitalized (UserName). "camelCase" means the first letter is lowercase but later words are capitalized (userName). "snake_case" means all lowercase with underscores. "CONSTANT_CASE" means all uppercase with underscores.
| Language | Variables | Functions | Classes | Constants | Files |
|---|---|---|---|---|---|
| JavaScript | camelCase | camelCase | PascalCase | CONSTANT_CASE | kebab-case or camelCase |
| TypeScript | camelCase | camelCase | PascalCase | CONSTANT_CASE | kebab-case or camelCase |
| Python | snake_case | snake_case | PascalCase | CONSTANT_CASE | snake_case |
| Ruby | snake_case | snake_case | PascalCase | CONSTANT_CASE | snake_case |
| Rust | snake_case | snake_case | PascalCase | SCREAMING_SNAKE_CASE | snake_case |
| Go | camelCase / PascalCase | camelCase / PascalCase | PascalCase | PascalCase or camelCase | snake_case |
| Java | camelCase | camelCase | PascalCase | CONSTANT_CASE | PascalCase (matches class) |
| Kotlin | camelCase | camelCase | PascalCase | CONSTANT_CASE | PascalCase (matches class) |
| Swift | camelCase | camelCase | PascalCase | camelCase (lowercase) | PascalCase (matches class) |
| C# | camelCase | PascalCase | PascalCase | PascalCase | PascalCase |
| C++ | snake_case (Google) or camelCase | snake_case or camelCase | PascalCase | CONSTANT_CASE | snake_case (.cc/.h) |
| C | snake_case | snake_case | (N/A — structs use snake_case) | CONSTANT_CASE | snake_case |
| PHP | camelCase or snake_case | camelCase (modern PSR-12) | PascalCase | CONSTANT_CASE | PascalCase (PSR-4) |
| Elixir | snake_case | snake_case | PascalCase (modules) | @module_attrs (snake) | snake_case |
| Scala | camelCase | camelCase | PascalCase | PascalCase (singletons) | PascalCase |
| Dart | camelCase | camelCase | PascalCase | camelCase (lowerCamel) | snake_case |
| Haskell | camelCase | camelCase | PascalCase (types/data) | camelCase | PascalCase (matches module) |
| Lua | snake_case or camelCase | snake_case or camelCase | PascalCase | CONSTANT_CASE | snake_case |
| Bash | snake_case (local) / CONSTANT_CASE (env) | snake_case | (N/A) | CONSTANT_CASE | kebab-case or snake_case |
| SQL | snake_case (columns) | UPPERCASE (keywords) | PascalCase or snake_case (tables, varies) | (N/A) | snake_case |
Things worth noting
Go's visibility-via-capitalization
Go is unusual: it uses identifier capitalization to determine whether something is exported (visible outside the package). Exported names are PascalCase. Unexported names are camelCase. So fmt.Println is exported (capital P), but fmt.formatRune would be internal (lowercase f). This means in Go, you don't choose between camelCase and PascalCase based on what kind of identifier it is — you choose based on whether you want it visible to other packages.
Swift's lowercase constants
Swift is unique in keeping constants in camelCase rather than CONSTANT_CASE: let maxRetryCount = 3 not let MAX_RETRY_COUNT = 3. The Swift API Design Guidelines argue that constants are just values that happen not to change, and they shouldn't shout.
C#'s PascalCase methods
C# uses PascalCase for methods, even instance methods. So you write user.GetName() not user.getName(). This breaks with Java's convention even though the two languages otherwise look similar.
Python's class methods convention
Python uses snake_case for everything that isn't a class — including methods. So a class UserAccount has methods like get_name(), not getName(). Combined with the PascalCase class names, Python code has a distinctive visual rhythm.
Rust's strict convention enforcement
Rust's compiler emits warnings if you don't follow the convention. Variables and functions must be snake_case; types and traits must be PascalCase; constants must be SCREAMING_SNAKE_CASE. You'll get a non_snake_case warning if you write a variable like userName in Rust code. Most other languages don't enforce convention this strictly.
JavaScript's file-naming chaos
JavaScript projects don't have a unanimous file-naming convention. React projects often use PascalCase for component files (UserProfile.jsx) and camelCase for utility modules (fetchUser.js). Other JS projects use kebab-case throughout (user-profile.js). Both are valid; pick one and be consistent.
How JSON keys complicate everything
JSON is language-agnostic but its keys have to match a convention somewhere. Two patterns are common:
- camelCase JSON: matches JavaScript convention, common in REST APIs that target JS frontends.
{"userId": 123, "createdAt": "..."} - snake_case JSON: matches Python/Ruby convention, common in APIs built in those languages.
{"user_id": 123, "created_at": "..."}
If your backend is Python and your frontend is JavaScript, you either let JSON match one side (and the other side converts), or you do the conversion at the API boundary. Tools like Rails' jbuilder, Django REST Framework, and most ORMs offer automatic camelCase/snake_case conversion at the serialization layer.
Migrating between conventions
If you need to convert identifiers from one convention to another in bulk — say, migrating a Python codebase to TypeScript, or generating snake_case database columns from camelCase domain models — our bulk converter handles whole files. Paste the column list, switch to the target case, and copy the output.
For one-off conversions while you code, the main case converter is a single page that handles all the conventions in this table.
The bigger principle
The naming convention you follow signals which community you're writing for. Pythonists read snake_case faster because they've been training on it for years. JavaScript developers do the same with camelCase. The choice is rarely about which is objectively better — it's about which one your readers expect.
That makes the rule simple: in any language, follow the language's documented conventions. If the language has multiple competing conventions (PHP, JavaScript, C++), follow whatever your team has settled on. The cost of inconsistency is paid by every reader of the code, every time.