Every programming language, framework, and platform has its own naming convention — and violating them silently makes your code look wrong even when it works correctly. This guide covers the five common case styles, where each one belongs, and how to convert between them quickly.
The Five Case Styles
camelCase
Starts lowercase, each subsequent word capitalised. No separators.
firstName getUserById parseResponseData
Where it lives: JavaScript variables, functions, and object properties. Java variables. JSON keys (by convention). Swift variables and functions.
PascalCase (UpperCamelCase)
Like camelCase, but the first letter is also capitalised.
UserProfile HttpRequest DatabaseConnection
Where it lives: JavaScript/TypeScript class names and React components. C# everything. Python class names. Go exported identifiers.
snake_case
All lowercase, words separated by underscores.
user_id get_user_by_id parse_response_data
Where it lives: Python variables, functions, and module names (PEP 8). Ruby variables and methods. PostgreSQL column names. C variables and functions. Rust variables.
SCREAMING_SNAKE_CASE
Like snake_case but ALL CAPS.
MAX_RETRY_COUNT DATABASE_URL API_TIMEOUT_MS
Where it lives: Constants in almost every language — JavaScript const, Python module-level constants, Java static finals, C/C++ macros and #define.
kebab-case
All lowercase, words separated by hyphens.
user-profile get-user-by-id api-timeout
Where it lives: HTML attributes and custom element names. CSS class names and custom properties (--primary-color). URL slugs and route paths. YAML keys. npm package names.
Why Conventions Matter More Than You Think
It is tempting to treat case style as cosmetic. It is not.
APIs break. A REST API returning user_id (snake_case) needs to match what the frontend expects. If your frontend auto-converts JSON keys to camelCase (as Axios can, or as you might do manually), a mismatch silently passes undefined to your template.
Linters fail. ESLint's camelcase rule, Python's flake8, and RuboCop all flag case violations. A codebase that mixes conventions generates noisy lint output that masks real errors.
Grep and search break. If half your codebase uses getUser and half uses get_user, a regex search for one misses the other. Inconsistency makes tools less useful.
Database migrations fail. PostgreSQL is case-insensitive by default — UserID, userid, and user_id may resolve to the same column. MySQL with a case-sensitive collation treats them differently. Mixing conventions in schema files creates subtle bugs that only surface in specific environments.
The Cross-Language Problem
Most real projects mix languages: a Python backend, a JavaScript frontend, a PostgreSQL database, and a Docker Compose YAML. Each layer has its own convention:
| Layer | Convention |
|---|---|
| Python functions | snake_case |
| JavaScript variables | camelCase |
| PostgreSQL columns | snake_case |
| CSS classes | kebab-case |
| Environment variables | SCREAMING_SNAKE_CASE |
| Docker service names | kebab-case |
This means every time data crosses a layer boundary, you need a deliberate choice: do you convert, or do you pick one convention and break from the other layer's standard?
Common patterns:
-
Snake-to-camel at the API boundary: Python returns
{"user_id": 1}, JavaScript readsuserId. Use a JSON deserialiser that auto-converts, or handle it explicitly. -
PascalCase in React, kebab in CSS: A component called
UserCardmaps to a class.user-card. Many developers maintain this mental mapping automatically.
Conversion Tips
When you need to convert between styles — renaming a database column to match a frontend field, preparing a blog slug from a title, or matching a third-party API's naming — doing it by hand is slow and error-prone.
Some quick command-line approaches:
# snake_case to camelCase (Python)
echo "user_profile_id" | python3 -c "
import sys, re
s = sys.stdin.read().strip()
parts = s.split('_')
print(parts[0] + ''.join(w.capitalize() for w in parts[1:]))
"
# → userProfileId
Or for batch renaming across a codebase, use your editor's refactoring tools (VS Code's rename symbol, JetBrains' refactor → rename) rather than a raw find-and-replace — these understand scope.
For quick one-off conversions without the terminal, SnappyTools' Case Converter converts between camelCase, PascalCase, snake_case, SCREAMING_SNAKE_CASE, kebab-case, and Title Case in one click — paste text, pick the output format.
A Practical Checklist
Before merging a PR that touches naming:
- [ ] New variable/function names match the language convention for that context
- [ ] Any new database columns use the project's established column naming scheme
- [ ] New CSS classes follow the project's BEM / utility / module pattern
- [ ] Environment variable names are SCREAMING_SNAKE_CASE
- [ ] New URL paths use kebab-case
- [ ] API response keys match what the consuming layer expects (or a conversion layer exists)
What naming convention bugs have bitten you hardest? Drop a comment — I'm particularly curious about edge cases in Python/JS projects that cross the snake_case/camelCase boundary.
