Case Conventions for Developers: camelCase, snake_case, PascalCase, and kebab-case

Case conventions look cosmetic until a project grows. Then inconsistent names start creating friction: API fields do not match front-end variables, CSS classes look different from file names, and database columns need manual translation. A case converter is useful because it handles the mechanical part, but the important decision is knowing which style belongs in which context.

Use conventions that match the ecosystem

JavaScript and TypeScript commonly use camelCase for variables and functions, while React components use PascalCase. Python favors snake_case for variables, functions, and module names. CSS classes and URL slugs often use kebab-case because hyphens are readable in HTML and safe in paths. Environment variables and many constants use SCREAMING_SNAKE_CASE to signal that the value is configured outside normal code flow.

Following local convention is more important than personal preference. A Python module full of camelCase names is harder for Python developers to scan, even if the code still runs. A CSS codebase with mixed underscores and hyphens makes search and refactoring slower. Consistency reduces cognitive load.

Translate at boundaries

Many applications need more than one convention. A database may expose created_at, a JSON API may return createdAt, and a UI label may display "Created at." Treat these as boundaries. Convert names deliberately when data crosses from one layer to another instead of letting every layer invent its own version.

• Database columns: prefer snake_case unless your framework has a strong alternative.
• JSON keys: use one style per API and document it.
• CSS classes: kebab-case is readable and common.
• Classes and components: PascalCase keeps types visually distinct.

Watch for acronyms and numbers

Acronyms are where many automatic conversions fail. Decide whether your project writes apiResponse or APIResponse, then keep that rule. Numbers also need attention: addressLine2, address_line_2, and address-line-2 are all reasonable in different contexts, but switching between them randomly makes code harder to search.

Create a naming checklist

Before adding a new field or function, ask three questions: Where will this name appear? Which convention does that layer expect? Will another layer need a translated version? This small habit prevents a large class of inconsistent naming bugs. Use a case converter for the transformation, but use a convention guide for the decision.