Naming Conventions for Developers: camelCase, snake_case, kebab-case
A practical naming map across JavaScript, Python, SQL, CSS, and API schemas.
Why naming conventions matter more than people admit
Naming conventions are not only style preferences. They affect readability, searchability, code generation, schema evolution, docs quality, and how quickly a new engineer can understand what belongs together.
Teams usually run into trouble when names drift across boundaries: a frontend expects camelCase, the database stores snake_case, CSS classes are in kebab-case, and an API returns a mix of all three. The issue is rarely that one convention is objectively best. The issue is inconsistency.
A practical map by ecosystem
| Context | Common convention | Example |
|---|---|---|
| JavaScript / TypeScript variables | camelCase | userProfile, createdAt |
| Classes / React components | PascalCase | UserProfileCard |
| Python functions and variables | snake_case | user_profile, created_at |
| SQL columns | snake_case | created_at, user_id |
| CSS classes | kebab-case | user-profile-card |
| Environment variables | UPPER_SNAKE_CASE | DATABASE_URL |
The real rule: be consistent at each boundary
The healthiest approach is usually to choose one convention per layer and convert at the edges where necessary. For example, a backend may expose snake_case in SQL, map it to camelCase in application code, and still keep CSS in kebab-case without confusion.
Problems start when one public API mixes createdAt, user_id, and account-statusin the same schema. That forces consumers to memorize arbitrary exceptions and makes generated types, docs, and validation rules harder to trust.
API naming strategy that scales
- Pick one external naming convention for request and response bodies.
- Document it once in API docs, examples, and schema generation tooling.
- Convert internally if needed rather than leaking mixed naming across the boundary.
- Keep errors and metadata consistent too, not only the happy-path fields.
Common naming mistakes in real projects
Short names save keystrokes but cost clarity. Shared codebases age better with obvious field names.
Public contracts need deprecation windows, aliases, or versioning if consumers already depend on them.
Names like api_user_id_v2_json become noise fast. The field should describe meaning, not implementation history.
Generators are helpful, but the public naming system should be intentional rather than accidental.
Migration tip for renaming fields safely
Renaming fields is rarely just a search-and-replace. Clients, dashboards, imports, saved filters, and generated types may all depend on the old name. A safer migration is usually: support both names briefly, emit warnings, update docs and examples, then remove the old alias after the transition window.
This matters especially at API boundaries, where a “small cleanup” can become a silent breaking change for every consumer if aliases or versioning are skipped.
A naming system that survives scale
Good naming conventions do more than make files look tidy. They reduce translation cost between layers. When a concept like billing account status turns into billing_account_status in SQL,billingAccountStatus in TypeScript, and billing-account-status in CSS, engineers can still recognize it as one idea.
That recognition matters in debugging, search, refactoring, and onboarding. If names drift unpredictably, even generated docs and schema tooling become less trustworthy because the same domain term keeps mutating without a rule.
Hard cases: acronyms, plurals, and legacy baggage
Decide early whether your team wants APIKey or ApiKey, userID or userId, then keep the rule consistent in docs and generators.
Names such as users, orderItems, and selectedTags should reveal whether the field is a list, not leave readers guessing from context.
Sometimes the ideal convention loses to backward compatibility. In that case, document the exception instead of pretending it does not exist.
Code generators can preserve consistency, but they should follow your naming policy rather than inventing the public contract accidentally.
A simple policy teams can actually follow
- Pick one convention per layer instead of forcing one style everywhere.
- Document boundary conversions so API, DB, and frontend names stay intentionally related.
- Capture exceptions explicitly for acronyms, vendor payloads, or historical fields.
- Review names for meaning, not just casing; a perfectly cased vague field name is still a bad name.