DEV Community

Snappy Tools
Snappy Tools

Posted on • Originally published at snappytools.app

camelCase, snake_case, kebab-case: A Developer's Field Guide to Naming Conventions

#webdev #tools #productivity #beginners

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 reads userId. Use a JSON deserialiser that auto-converts, or handle it explicitly.
  • PascalCase in React, kebab in CSS: A component called UserCard maps 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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)