Database column names, CSS class names, and URL paths don't just happen to use different casing conventions — each choice reflects a constraint from the environment where that identifier will be used, and mixing conventions across a codebase creates maintenance debt that compounds invisibly until it suddenly matters
The previous articles on this site covered code naming conventions, Unicode case challenges, title case style guide differences, and case sensitivity in login systems. This article addresses case conventions in data systems — specifically why database identifiers, JSON field names, and environment variables each have their own conventions, and what breaks when you ignore them.
Database identifiers: the case-sensitivity landmine
SQL databases handle identifier case differently depending on the database system:
PostgreSQL: converts unquoted identifiers to lowercase automatically — CREATE TABLE Users creates a table named users. If you then query SELECT * FROM "Users" (quoted), you'll get "table not found" because the actual table is named users. This trips up developers migrating from case-insensitive databases or ORMs that quote identifiers.
MySQL/MariaDB: case sensitivity for table names depends on the operating system and the lower_case_table_names setting. On Linux, table names are case-sensitive by default; on Windows and macOS, they're case-insensitive. A codebase developed on macOS where Users and users are the same table can fail on a Linux production server where they're different tables.
SQL Server: case sensitivity is controlled by the database collation — a database with a case-sensitive collation (Latin1_General_CS_AS) treats Users and users as different; one with a case-insensitive collation (Latin1_General_CI_AS) treats them as the same.
The convention that avoids most of these problems: use lowercase snake_case for all database identifiers (user_accounts, order_line_items) — lowercase identifiers behave consistently across databases and operating systems.
JSON field names: why APIs are inconsistently cased and what it costs
JSON has no specified convention for field naming. Different ecosystems have settled on different conventions:
camelCase (firstName, lastName, orderId): standard in JavaScript, TypeScript, and APIs designed for JavaScript clients. JSON.parse in JavaScript produces objects whose properties are accessed with dot notation where camelCase is the natural convention.
snake_case (first_name, last_name, order_id): standard in Python, Ruby, and APIs designed for these ecosystems. Python's naming convention makes snake_case the natural choice.
PascalCase (FirstName, LastName, OrderId): used in some .NET and C# APIs where the convention matches C# property naming.
The cross-ecosystem problem: a Python backend returning snake_case JSON consumed by a JavaScript frontend requires either: client-side conversion (transforming first_name → firstName in the JavaScript layer), or accepting the mismatch and using response.first_name instead of response.firstName in JavaScript (inconsistent with JavaScript convention).
Many frameworks provide automatic case conversion (Python's Django REST Framework, Pydantic with alias_generator, JavaScript clients using camelcase libraries) — but this introduces a mapping layer that can become a source of bugs when the transformation is partial or inconsistent.
Environment variables: SCREAMING_SNAKE_CASE and why
Environment variables are almost universally SCREAMING_SNAKE_CASE (DATABASE_URL, AWS_SECRET_ACCESS_KEY, MAX_RETRY_ATTEMPTS) — all uppercase, words separated by underscores.
The reason is partially historical (Unix shells are case-sensitive, and uppercase was conventionally used for environment variables to distinguish them from shell variables) and partially practical — environment variables must be safe to use in shell scripts, where a variable named database-url (with a hyphen) would be interpreted as database minus url in arithmetic context. Underscores are the only safe word separator in shell variable names.
The convention is effectively universal enough that frameworks, deployment platforms (Kubernetes, Docker, Heroku, Fly.io), and secret managers all expect environment variables in SCREAMING_SNAKE_CASE. Deviating from this creates friction with tooling.
File names: the OS-level case problem
File name case sensitivity follows the operating system's filesystem:
macOS HFS+/APFS (default): case-insensitive (but case-preserving) — Component.tsx and component.tsx cannot coexist in the same directory, and import './Component' and import './component' both work.
Linux ext4/XFS: case-sensitive — Component.tsx and component.tsx are different files; import './component' fails if the file is named Component.tsx.
The cross-platform development problem: a React component file named MyComponent.tsx imported as import MyComponent from './mycomponent' works on macOS (case-insensitive filesystem) but fails on the Linux production server. This is a class of bug that doesn't appear in development and only manifests in deployment — notoriously frustrating to debug the first time it occurs.
The standard solution: be consistent with capitalization in both the file name and the import path, and enforce this with linting tools (ESLint's import/no-unresolved rule or TypeScript's forceConsistentCasingInFileNames option flag inconsistencies).
CSS class names: why BEM uses dashes and why that matters
CSS class names use kebab-case (primary-button, card-header, nav-link) — all lowercase, words separated by hyphens.
The reason: CSS property names themselves use kebab-case (background-color, font-size, margin-top), and HTML attributes are case-insensitive. Using camelCase in class names (primaryButton) works but is inconsistent with the surrounding language conventions; using PascalCase (PrimaryButton) is meaningfully inconsistent and reads as unusual.
BEM methodology (Block, Element, Modifier) doubles down on kebab-case within segments: .card__card-header--highlighted — using double underscores for element relationships and double hyphens for modifiers.
CSS Modules (common in React/Vue component-based development) allow camelCase class names used in JavaScript (styles.primaryButton) mapped to kebab-case in the generated CSS — providing the best of both: JavaScript-native naming in JS code, CSS-native naming in stylesheets.
How to use the Case Converter on sadiqbd.com
- For cross-system naming: convert a natural-language name to the appropriate convention for each context — "user account order" →
user_account_orderfor database columns,userAccountOrderfor JavaScript variables,USER_ACCOUNT_ORDERfor environment variables,user-account-orderfor CSS and URLs - For API integration: when consuming an API with a different naming convention than your code uses, the converter helps plan the field-name translation between systems
- For code review preparation: identify inconsistencies in a proposed field-naming scheme by converting between conventions and checking for collisions or ambiguities
Frequently Asked Questions
Is there a "best" single convention that works across all systems? No — the optimal convention is system-specific, and trying to use one convention universally means fighting against at least some environments' natural grain. The practical goal is consistency within each system (all database columns use snake_case, all JavaScript variables use camelCase, all environment variables use SCREAMING_SNAKE_CASE) and explicit, automated transformation at boundaries between systems (API responses auto-converted from snake_case to camelCase, ORM field mappings handled by the framework). Attempting to use camelCase in database column names or kebab-case in environment variables creates friction with tooling and convention for no benefit.
Is the Case Converter free? Yes — completely free, no sign-up required.
Try the Case Converter free at sadiqbd.com — convert any text between camelCase, snake_case, SCREAMING_SNAKE_CASE, kebab-case, PascalCase, and more.
