Text Case Format Converter Reference

What Is snake_case?

Inside Python codebases, database schemas, and configuration files, one naming pattern appears more often than any other: lowercase words joined by underscores. That pattern is snake_case, and understanding where it is required versus where it is merely conventional determines how you name identifiers before writing a single line of code.

What is snake_case?

Origin and history

The underscore-joined, all-lowercase style predates the term "snake_case" itself. C programmers used it for UNIX system calls in the 1970s (names like open(), read(), and write()), and the POSIX API standardized it.¹ Python's PEP 8, published in 2001, formalized snake_case for the entire language: variables, functions, module names, and method names all follow it.² The term "snake_case" gained widespread use in developer discussions in the 2010s as a shorthand for the pattern, possibly because an underscored identifier lying flat resembles a snake.

Ruby adopted snake_case from its earliest versions, influenced by Perl and Python, and the community style guide has required it since the mid-2000s. Rust made snake_case a compiler-enforced convention in 2015, escalating it from a style recommendation to a warning that Clippy can turn into a hard error.³ The Linux kernel coding style, maintained by Linus Torvalds, mandates snake_case for all function and variable names across the entire kernel codebase, making it one of the oldest and most consistently enforced naming conventions in software history.⁴

Where snake_case is used

Python enforces snake_case for all non-constant, non-class identifiers per PEP 8.² Ruby follows the same convention, as does Elixir and Rust for function and variable names. SQL databases, like PostgreSQL, MySQL, and SQLite, use snake_case for table and column names by convention, not specification.⁵ When a backend built in any of these languages exposes data to a JavaScript frontend that uses camelCase, a conversion layer at the API boundary is necessary to keep both sides consistent with their respective language conventions.

snake_case in configuration and environment variables

Environment variables in Linux shells and Docker use SCREAMING_SNAKE_CASE (all-caps snake_case) to signal that a value is external to the application and injected at runtime. Configuration files in YAML, TOML, and many .properties formats use snake_case keys for the same reason: the format is readable, unambiguous, and survives case normalization across different operating systems and deployment targets. Docker Compose, Kubernetes manifests, and CI pipeline files all follow this convention, which means the same naming style travels from local development through staging to production without modification.

The cross-platform durability is the practical payoff. A snake_case key reads identically on a case-sensitive Linux container and a case-insensitive Windows laptop, so a configuration value set in one environment resolves the same way in another. Case-sensitive filesystems are the norm in production, and a naming style that does not depend on letter case avoids the class of bug where a key written on a developer's machine fails to load on a server. Keeping environment and config keys in snake_case is one less thing to reconcile when code moves between operating systems.

Common pitfalls

Mixing snake_case and camelCase in the same codebase is the most common mistake: it usually indicates a boundary between two systems (a JavaScript frontend and a Python backend) where a conversion layer was skipped. Secondly, using SCREAMING_SNAKE for non-constants (a Python variable named MAX_VALUE when it is not a constant) creates misleading signals for readers. Thirdly, double underscores (__) have special meaning in Python (dunder methods, name mangling), and using them in regular variable names creates confusion.⁶

A subtler pitfall is inconsistent abbreviation handling: a codebase that uses both "user_id" and "usr_id" forces readers to guess whether the same concept appears under two different names. Establishing a project-wide abbreviation convention and documenting it in the style guide prevents this drift. Another common error is applying snake_case to language-specific constructs that follow different rules: Java class names should be PascalCase, not snake_case, and JavaScript constructor functions should also be PascalCase even though the rest of the JavaScript codebase uses camelCase.

Why snake_case dominates in backend ecosystems

Backend languages converge on snake_case for different reasons, but the result is a consistent convention across the server-side ecosystem. Python's PEP 8 formalized it. Ruby's community style guide reinforced it. Rust's compiler enforces it. SQL databases normalize unquoted identifiers to lowercase, making snake_case the only multi-word format that survives case normalization cleanly. When a JavaScript frontend consumes data from any of these backends, a conversion layer is needed at the API boundary. CapyToolkit's Text Case Format Converter handles that conversion in one pass, whether you are mapping a single field or an entire schema.

The dominance of snake_case on the server side creates a clear pattern: frontend code uses camelCase, backend code uses snake_case, and the API boundary is where the translation happens. Tools like camelcase-keys in the Node.js ecosystem and Pydantic's alias_generator in Python automate this translation, but understanding the underlying convention helps you debug mismatches when a field name silently fails to map between the two sides.

snake_case in Rust: the language standard and Clippy lint enforcement

Rust enforces snake_case for function names, variable names, and module names at the compiler level. Unlike Python's PEP 8 (a style guide), Rust's snake_case requirement is a compiler warning that the Clippy linter escalates to an error in strict configurations. This compiler-level enforcement means that every Rust crate published to crates.io follows snake_case for its public API surface by default, making the convention pervasive across the entire Rust ecosystem rather than dependent on individual project configuration.

The Rust compiler emits a non_snake_case warning for any function or variable name that does not follow snake_case. The Clippy linter includes this as the clippy::non_snake_case lint. Adding #![deny(clippy::all)] to your lib.rs or main.rs turns this warning into a compile error, making snake_case a build requirement rather than a suggestion. Most Rust projects include this or a similar directive in their top-level file.

Clippy naming lint rules

Clippy's naming lints cover non_snake_case for functions and variables, non_camel_case_types for struct and enum names, and non_upper_case_globals for constants. These three lints together enforce the complete Rust naming convention in a single pass. Run cargo clippy to see all violations before your first commit. Paste your planned function and variable names into this converter to preview the snake_case form before writing the code, which avoids Clippy violations on the first run.

snake_case in database migration tools: Alembic, Flyway, and Liquibase

Database migration tools generate or accept column names that must be snake_case to match the ORM models that read them. Getting column names right before writing a migration prevents the need for a subsequent renaming migration, which is a destructive operation requiring coordination across all deployed application versions. A column rename in production forces every running instance to stop reading the old name before the new name is deployed, so fixing the name before the first migration runs eliminates a costly coordination step that grows harder as the application scales.

Alembic (Python/SQLAlchemy), Flyway (Java/JDBC), and Liquibase (Java) all generate migrations from schema descriptions. Alembic's autogenerate mode derives column names from SQLAlchemy model attribute names, which are snake_case in Python. Flyway and Liquibase accept column names as strings in XML or YAML changeset files. In all three tools, using non-snake_case column names creates a mismatch with ORM attribute names and requires explicit column mapping.

Verifying column names before running irreversible migrations

Renaming a column in a production database requires all running application instances to stop reading the old column name before the new name is deployed. Paste your planned column names (which might come from PascalCase class members or camelCase API fields) into this converter, verify the snake_case output, and use those names in your migration file before running it. CapyToolkit processes each line independently, so checking a full table schema takes one paste and catches naming errors before a migration reaches production.

Try in the tool

What Is camelCase?

Across JavaScript, TypeScript, Java, Swift, and Kotlin, one naming pattern governs variables, function names, and object properties: the first word lowercase, every subsequent word capitalized, no separators. That pattern is camelCase, and its "humps",the uppercase letters rising from the lowercase baseline,give it the name.

What is camelCase?

Origin and history

The style appeared in early programming languages of the 1960s and 1970s and was codified in the Smalltalk and C++ communities.¹ Java's naming conventions, documented in Sun's Java Code Conventions (1997), explicitly required camelCase for method and variable names.² JavaScript, which followed a C-family syntax model, adopted the same convention. The JSON data format's prevalence reinforced camelCase as the web's default property name format. The name itself is a visual metaphor: the uppercase letters in the middle of a camelCase identifier resemble the humps of a camel, and this informal name stuck because it was more memorable than technical alternatives like "mixedCase" or "internalCapitalization." By the time TypeScript arrived in 2012, camelCase was so deeply embedded in web development culture that adopting it was never a question.

Where camelCase is used

JavaScript and TypeScript use camelCase for all variables, function parameters, and object property names; the Airbnb Style Guide, Google Style Guide, and Standard.js all specify it.³ Java uses camelCase for method names and local variables. Swift and Kotlin follow the same convention. The breadth of languages that adopt camelCase for their runtime identifiers means that a developer switching between JavaScript on the web, Java on the server, and Swift on mobile encounters the same naming pattern in every context.

camelCase in JSON and API response formats

JSON property names in REST APIs are almost universally camelCase, making it the most common data exchange format for web development. Building on this, React's JSX attribute names follow camelCase (className, onClick, htmlFor) rather than the HTML attribute equivalents. When a Python or Ruby backend returns snake_case JSON, a conversion at the API boundary or in the fetch layer maps those fields to camelCase before they reach component code.

The backend-to-frontend conversion is where most camelCase bugs originate. A Python service returns snake_case JSON, and unless a serializer maps each field to camelCase, the frontend receives keys that do not match the component props expecting them. Frameworks like Django REST Framework and FastAPI let you configure a global camelCase renderer so the conversion happens in one place rather than per endpoint. Generating both the snake_case database column and the camelCase JSON key from a single source name keeps the two in sync and makes the boundary easy to audit when a field silently fails to map.

Common pitfalls

Acronyms are the most common source of camelCase inconsistency. "XMLParser" (all-caps acronym) vs. "xmlParser" vs. "XmlParser": teams vary in their preference. The JavaScript and TypeScript communities generally prefer treating acronyms as words: "xmlParser", "httpClient", "userId".³ Secondly, mixing camelCase with snake_case at system boundaries (a JavaScript frontend receiving snake_case data from a Python backend) requires an explicit conversion layer that is often forgotten.

A third pitfall is inconsistent treatment of two-letter words: "id" as a standalone word in camelCase should be lowercase ("userId"), but some teams capitalize it as "userID" by analogy with acronyms. The TypeScript and JavaScript style guides from Google and Airbnb both recommend "userId" over "userID," but enforcement requires a linter rule because the inconsistency is invisible in casual code review. Finally, developers sometimes apply camelCase to constants that should be SCREAMING_SNAKE_CASE, creating a visual ambiguity between mutable variables and immutable values.

Acronym handling strategies for consistent camelCase

Teams that work with protocols and formats containing acronyms benefit from a consistent strategy before they start naming identifiers. Decide early whether your codebase treats acronyms as regular words ("userId", "httpClient") or preserves all-caps forms ("UserID", "HTTPClient"). Document the decision in your team style guide and enforce it with a linter rule. CapyToolkit's Text Case Format Converter can verify that your existing identifiers follow the chosen convention after you have made the decision.

The Google JavaScript Style Guide and the Airbnb style guide both recommend treating acronyms as words, which means "xmlParser" and "httpClient" are preferred over "XMLParser" and "HTTPClient." The Microsoft C# Coding Conventions take a different approach: acronyms of three or more letters use PascalCase ("XmlParser"), while two-letter acronyms stay all-caps ("IOStream"). Whichever strategy you choose, consistency matters more than the specific rule, because inconsistent acronym handling forces readers to guess whether a given identifier follows the word rule or the acronym rule.

camelCase in Swift, Kotlin, and mobile development naming conventions

Swift and Kotlin both enforce camelCase for function and variable names through their language style guides and official tooling. Mobile development with these languages follows the same camelCase convention as JavaScript and TypeScript, making camelCase the dominant naming pattern across web, iOS, and Android codebases. When a team builds shared SDKs that target both web and mobile platforms, camelCase is the one convention that needs no translation between any platform in the stack.

Swift's API Design Guidelines specify camelCase for all names except types, which use PascalCase.⁴ Swift's swiftlint tool enforces naming conventions, including the identifier_name rule that flags names with too few characters and the type_name rule that requires PascalCase for types. Variable and function names in Swift that use snake_case produce style warnings in any project with SwiftLint configured.

Kotlin naming conventions and Android development

Kotlin's official coding conventions, maintained by JetBrains and adopted by the Android team, require camelCase for function names, variable names, and parameters.⁵ Android's Jetpack Compose uses camelCase for most composable function names by convention. In Compose, functions with the @Composable annotation that return a value use camelCase; functions that return Unit and produce UI content use PascalCase. Paste your planned function and variable names into this converter to verify the camelCase format before writing Swift or Kotlin code.

JSON Schema property naming and OpenAPI 3.0 object naming conventions

JSON Schema specifies the structure of JSON objects, including the property names. OpenAPI 3.0 builds on JSON Schema to define REST API request and response objects. Property names in both formats use camelCase by convention when the API serves JavaScript frontends, though no specification mandates it. Understanding which casing convention your API adopts before writing the schema avoids the costly refactoring that results from discovering a mismatch after client code has already been generated against the wrong property name format.

OpenAPI property names appear in both the schema definition and in generated client code. A property name user_id in an OpenAPI spec becomes user_id in all generated clients unless a naming transformer is configured. A property named userId generates camelCase identifiers matching JavaScript and TypeScript conventions without any transformation. Paste your planned API property names into this converter to verify the camelCase format before writing the OpenAPI spec.

Swagger Codegen naming and camelCase output

Swagger Codegen and OpenAPI Generator produce TypeScript, Java, and Python clients from OpenAPI specs. A naming configuration flag forces all generated property names to camelCase regardless of the spec's own naming convention, which means a single spec file can serve clients in multiple languages without manual post-processing. Understanding this matters when your spec uses snake_case (suitable for Python clients) but you also want TypeScript clients with camelCase. Knowing the camelCase equivalents of your snake_case spec fields helps you verify the generated TypeScript output matches your expectations before committing the spec. CapyToolkit converts each line independently, so previewing the full set of property names takes one paste.

Try in the tool

What Is PascalCase?

When every word in an identifier starts with an uppercase letter and no separator joins them,UserProfile, OrderLineItem, PaymentGateway,that is PascalCase. Also known as UpperCamelCase, it is the universal convention for named types: classes in C# and Java, interfaces in TypeScript, components in React, and message names in Protobuf.

What is PascalCase?

Origin and history

PascalCase takes its name from the Pascal programming language, which required this style for all identifiers in the 1970s.¹ Niklaus Wirth's design influenced later languages, and the convention carried forward into Delphi, C#, Java, and TypeScript. Microsoft's C# Coding Conventions (the most detailed public specification of PascalCase usage) require it for all publicly visible members: classes, methods, properties, events, namespaces, and enumerations.² The .NET ecosystem standardized this usage across Microsoft's libraries. The term "UpperCamelCase" emerged as a way to distinguish it from lowerCamelCase (camelCase), and both terms appear in style guides depending on the community. Java's original naming conventions from Sun Microsystems in the mid-1990s cemented PascalCase as the standard for class names across the JVM ecosystem, and Kotlin, Scala, and Groovy all inherited this convention when they were created.³

PascalCase in Swift structs, protocols, and enum types

Swift uses PascalCase for all types: classes, structs, enums, protocols, and type aliases.⁴ This makes Swift consistent with C#, TypeScript, and Kotlin on type naming. Swift developers coming from JavaScript apply the same camelCase-for-values, PascalCase-for-types distinction they already know. Understanding this split before you start writing Swift code prevents the common mistake of applying camelCase to type names that would trigger SwiftLint warnings in any professionally configured project.

Swift protocols use PascalCase and often end with a noun or an -able, -ible, or -ing suffix: Codable, Equatable, CustomStringConvertible. Protocol naming follows PascalCase consistently, which matters when you write a custom protocol as part of a framework API. Paste your planned protocol names into this converter to verify the PascalCase form before writing the protocol definition.

SwiftUI View names and the PascalCase requirement

SwiftUI views are Swift structs that conform to the View protocol. All SwiftUI views use PascalCase: ContentView, UserProfileView, OrderListRow. SwiftUI's own built-in views follow the same pattern: Text, Button, NavigationStack, LazyVStack. Naming a SwiftUI view with camelCase compiles correctly (Swift does not enforce naming conventions at the compiler level) but violates the convention and triggers SwiftLint warnings when type_name rules are configured. Paste your view name candidates into this converter before creating the file to verify the PascalCase form.

GraphQL type naming and PascalCase as the cross-language standard for named types

GraphQL type names use PascalCase as a cross-language standard. Schema-first API development in GraphQL starts with type names that appear in generated TypeScript, Python, Java, and Go code. Using PascalCase in the schema ensures the generated types in every language follow that language's type naming convention automatically. When a schema uses snake_case or camelCase for type names instead, every code generator requires a naming transformation plugin to produce idiomatic output in each target language, adding configuration complexity that PascalCase avoids entirely.

The GraphQL specification does not mandate PascalCase, but every major GraphQL tool enforces it by default. GraphQL Code Generator, Hasura, and Apollo Studio all produce PascalCase type names in their TypeScript output. A schema type named user_profile produces user_profile in TypeScript, which violates TypeScript conventions. Naming the schema type UserProfile produces UserProfile in TypeScript, matching the expected convention without any post-processing.

GraphQL Code Generator and the PascalCase type pipeline

GraphQL Code Generator reads your .graphql schema files and produces TypeScript type definitions. With the default configuration, every type, input, enum, and interface in the schema generates a corresponding TypeScript type with the same name. Schema type names that use PascalCase produce correctly named TypeScript types without any additional plugin configuration. Schema types that use snake_case or camelCase require a namingConvention plugin configuration to transform the output. Paste your planned type names into this converter before writing the schema to avoid needing that transformation plugin.

Where PascalCase is used

C# requires PascalCase for all types, methods, properties, namespaces, and public members per the Microsoft C# Coding Conventions.² TypeScript uses it for classes, interfaces, type aliases, and enumerations. Swift and Kotlin apply PascalCase to all type names (classes, structs, enums, protocols), making it the universal convention for named types across modern statically typed languages.

PascalCase in React, GraphQL, and Protobuf type naming

React requires PascalCase component names because JSX uses the first character to distinguish between HTML elements (lowercase tags) and React components (uppercase tags).⁵ Building on this, GraphQL type definitions and Protobuf message names use PascalCase universally,it is the cross-language convention for named types. When a single API serves clients in TypeScript, Python, and Go, PascalCase in the schema ensures every generated type follows its language's convention without post-processing. Even in Python, where snake_case dominates most identifiers, class names are PascalCase per PEP 8, which means a Python developer reading unfamiliar code can immediately distinguish type identifiers from variable and function names by their uppercase-first shape.

The cross-language benefit is most visible in code generation. A schema that uses PascalCase for its type names produces a class in C#, an interface in TypeScript, a message in Protobuf, and a struct in Go without any naming transform, because every one of those targets expects PascalCase for named types. When the schema deviates from PascalCase, each generator needs a plugin or configuration flag to fix the output, and the generated names then drift from what the rest of each codebase expects. Keeping the schema in PascalCase is the one choice that satisfies all targets at once.

Common pitfalls

The most common error is using PascalCase for variables instead of types: "const UserProfile = ..." when it should be "const userProfile = ...". Secondly, acronyms create inconsistency: "HttpRequest" (recommended by Microsoft for 3+ letter acronyms) vs. "HTTPRequest" (old style). The Microsoft convention is to use PascalCase for acronyms of three or more letters and all-caps only for two-letter acronyms (IO, UI). Yet many codebases still use ALL_CAPS for any acronym, creating mixed styles.

A third pitfall is applying PascalCase to enum members in languages where the convention differs: in TypeScript, enum members are PascalCase, but in Python, enum members are typically SCREAMING_SNAKE_CASE. When a team works across both languages, the inconsistency in enum naming can cause confusion about whether a PascalCase name refers to a type or a value. Finally, some developers apply PascalCase to file names (UserProfile.ts) while others use kebab-case (user-profile.ts), and this inconsistency in file naming creates friction in code reviews.

When to choose PascalCase over camelCase in a new codebase

Choosing between PascalCase and camelCase for a new project depends on the language and the type of identifier. As a rule of thumb, use PascalCase for types (classes, interfaces, enums, records) and camelCase for values (variables, function parameters, properties). This distinction signals intent to other developers: a PascalCase name tells the reader "this is a named type you can import or extend," while a camelCase name says "this is a value you pass around or mutate." CapyToolkit's Text Case Format Converter helps you enforce this split across a large codebase by converting batches of identifiers in one pass.

The choice also affects tooling: many IDEs provide different refactoring operations for types versus values, and consistent casing helps the tooling work correctly. When you generate code from a schema (OpenAPI, Protobuf, GraphQL), the code generator uses casing to decide whether to emit a class or a variable, so getting the convention right at the schema level prevents incorrect generated code.

Try in the tool

What Is kebab-case?

Because hyphens act as subtraction operators in most programming languages, kebab-case occupies a specific niche: it cannot be used for variable names in JavaScript, Python, Java, or C#, but it is the required format for URL slugs, CSS property names, HTML attributes, and CLI flags.¹² The name comes from the visual resemblance of hyphen-joined words to items on a skewer.

What is kebab-case?

Origin and history

Hyphen-separated lowercase identifiers predate the term "kebab-case". URL designers adopted hyphens as word separators because spaces are not valid in URLs (they require percent-encoding)³ and underscores were less visually distinct than hyphens. The W3C CSS Specification uses hyphen-case for all property names (background-color, font-family, margin-top)², and the HTML specification uses it for data attributes. The term "kebab-case" emerged in developer culture in the 2010s, with "lisp-case" as an older alternative name from Lisp programming traditions. The "kebab" name comes from the visual resemblance of hyphen-joined lowercase words to items on a skewer, and it stuck because it was more colorful than alternatives like "hyphen-case" or "dash-case." Before the term became standardized, different communities used different names: "spinal-case" appeared in some Ruby documentation, and "slug-case" was common in CMS and blogging platforms.

Where kebab-case is required

CSS property names are kebab-case by the W3C specification: background-color, font-size, border-radius. HTML data attributes require kebab-case: data-user-id, data-product-name. URL path segments and slugs use kebab-case per Google's URL guidelines, which explicitly recommend hyphens over underscores as word separators for SEO.⁴ Building on this, most CLI tool options use kebab-case flags such as dry-run, output-dir, and max-retries. npm and package names use kebab-case by npm registry convention.⁵ HTTP header names in many frameworks use kebab-case: Content-Type, Accept-Encoding, Cache-Control. Even in programming languages where kebab-case is not valid as an identifier, it appears in string literals, configuration keys, and protocol specifications that the language must parse. YAML and TOML configuration files frequently use kebab-case keys, and the Python or JavaScript code that reads those files encounters kebab-case strings that need conversion to the language's native identifier style.

Common pitfalls

The biggest pitfall is using kebab-case in a language where hyphens are operators. "my-variable" in JavaScript, Python, or Java is parsed as "my minus variable": a subtraction expression, not an identifier. This causes syntax errors or logic bugs depending on context. Secondly, forgetting the two-hyphen prefix for CSS custom properties: a property must start with two hyphens to be recognized as a custom value rather than a reference to an existing CSS property. Thirdly, mixing kebab-case and snake_case in URL design creates inconsistency that is hard to detect without a linter.

A fourth pitfall is assuming kebab-case and Train-Case are interchangeable: Train-Case capitalizes each word (Content-Type, Accept-Encoding) while kebab-case is all lowercase. HTTP headers use Train-Case in the protocol specification, but many HTTP client libraries normalize them to lowercase for comparison. Using the wrong case in a header name comparison can cause subtle bugs where a header is present but not matched.

Kebab-case in npm and package naming conventions

npm's registry enforces kebab-case for published package names. Understanding the rule prevents rejected package names during the publishing step and keeps your module identifiers consistent with the ecosystem. When you scope a package under an organization, both the scope and the package name follow kebab-case, and any deviation from this format results in a registry rejection that blocks the publish until you rename.

npm registry naming requirements

npm package names must be URL-safe, all lowercase, and use hyphens as separators. Names like my-utility-library, react-query, and lodash-es all follow kebab-case. Underscores are technically allowed but discouraged because they create visual confusion with snake_case identifiers in JavaScript code. The @scope/package-name scoped format also uses kebab-case for the package segment. Before registering a package name, run your candidate name through the kebab-case converter to verify it meets the format, then check the npm registry for existing matches.

The registry enforces the rule at publish time, so a non-conforming name fails the publish rather than the install. Names with uppercase letters, spaces, or leading dots are rejected outright, while names with underscores trigger a warning that the registry still accepts. Scoped packages (@org/name) keep both segments in kebab-case, and the scope must be a valid npm organization you control. Checking the name against the kebab-case format before you run publish avoids the awkward situation of discovering the rejection after you have already written documentation and CI steps that reference the rejected name.

Node.js module import variables versus package names

An npm package uses kebab-case in package.json and the registry, but the imported variable in your code uses camelCase: const myUtilityLibrary = require('my-utility-library'). Or you use a shortened alias: const utils = require('my-utility-library'). The package name and the import variable are different things with different casing rules. Kebab-case belongs in the package name, file names, and require() string arguments; camelCase belongs in the JavaScript identifier that holds the module reference.

Choosing between kebab-case and snake_case for your project context

Kebab-case and snake_case both use a word-separator character instead of letter-casing changes. Knowing where each one belongs prevents inconsistency when setting up naming conventions in a new project. The decision between them is rarely a matter of preference because each format is dictated by the context in which the identifier appears, and choosing the wrong separator produces either a syntax error in the language parser or a silent misconfiguration in the runtime environment.

Where kebab-case is required over snake_case

Kebab-case is required for CSS property names, HTML attributes, URL paths, CLI flags, and npm package names. In all these contexts, underscores either are not valid or create ambiguity. A flag written as "dry-run" follows the standard convention, whereas "dry_run" is non-standard for CLI tools. "background-color" is the W3C-specified CSS property, while "background_color" does not exist in the CSS specification. Choosing kebab-case here is not a preference but a hard requirement imposed by the specification or platform, and using the wrong format leads to silent failures.

Where snake_case is required over kebab-case

Snake_case is required for Python identifiers, PostgreSQL column names, and environment variable names across all major operating systems. It is preferred for YAML configuration keys in tools like Ansible and Kubernetes. In these contexts, hyphens either are not valid identifiers or signal subtraction at the language level, which means a kebab-case name passed to a Python or SQL parser triggers a syntax error rather than matching an expected identifier. user_id is a valid Python variable; user-id is a subtraction expression that produces an error at parse time. Matching the naming convention to the context prevents these errors and unexpected behavior at runtime.

Try in the tool

What Is CONSTANT_CASE?

When an identifier is written in all uppercase with underscores separating words (DATABASE_URL, MAX_RETRIES, SECRET_KEY), that is CONSTANT_CASE. Also called SCREAMING_SNAKE_CASE, it is the cross-language signal that a value is immutable at runtime and known at compile time or configuration loading time.¹

What is CONSTANT_CASE?

Origin and history

The ALL_CAPS convention for constants dates to C programming in the 1970s, where preprocessor macros (which look like constants but are substituted before compilation) were written in SCREAMING_SNAKE to distinguish them from runtime variables. The GNU Coding Standards formalized this for C.¹ Python's PEP 8 adopted the same convention for module-level constants.² Environment variables in UNIX shells have always been uppercase,PATH, HOME, USER,making CONSTANT_CASE the default format for any value injected from outside the process. The convention spread from C to C++, Java (where static final fields use SCREAMING_SNAKE), and eventually to JavaScript and TypeScript, where the community adopted it for module-level constants even though the language does not enforce immutability at the compiler level.

Where CONSTANT_CASE is used

Python uses SCREAMING_SNAKE_CASE for module-level constants per PEP 8: MAX_SIZE, ALLOWED_HOSTS, SECRET_KEY. JavaScript and TypeScript use it for imported constants and config values; the ESLint prefer-const rule combined with UPPER_CASE naming signals immutability. C and C++ preprocessor macros use ALL_CAPS by the GNU Coding Standards. Environment variables passed to processes via the OS environment are always CONSTANT_CASE: DATABASE_URL, REDIS_URL, PORT.³ Building on this, Docker Compose and Kubernetes ConfigMaps use CONSTANT_CASE for all injected configuration keys. AWS Lambda environment variables, Azure Function app settings, and Google Cloud Run environment variables all follow the same convention. Feature flag names in LaunchDarkly, Split, and Flagsmith use CONSTANT_CASE to distinguish them from regular configuration keys, making it easy to search for all feature flags across a codebase.

Common pitfalls

Using CONSTANT_CASE for non-constants creates false signals: a variable that changes at runtime but is named MAX_VALUE suggests to readers that it is immutable. Secondly, confusing CONSTANT_CASE with snake_case when reading environment variables: "database_url" in a config file is a snake_case key; when exported as an environment variable, it should be DATABASE_URL. Thirdly, acronyms in CONSTANT_CASE do not cause the per-letter-split problem that camelCase does: "API_KEY" and "HTTP_TIMEOUT" read clearly because every letter is already uppercase. A fourth pitfall is using CONSTANT_CASE for enum members in languages where the convention differs: TypeScript enums use PascalCase for members, while Python enums use SCREAMING_SNAKE_CASE. When a team works across both languages, applying the wrong convention to enum members creates an inconsistent API surface that confuses consumers of the shared types.

CONSTANT_CASE in Docker Compose and CI pipeline configuration

Container orchestration and CI configuration files are where CONSTANT_CASE environment variable names appear most often in practice. Understanding the conventions for these tools prevents misconfiguration that is hard to debug across environment boundaries. When a variable name uses the wrong casing in a Docker Compose file or a GitHub Actions workflow, the application code that reads it receives an undefined value instead of the expected configuration, and the failure only appears at runtime in the deployed environment rather than in local testing.

Docker Compose environment variable syntax

In docker-compose.yml, the environment key accepts either a list of KEY=value strings or a map of KEY: value pairs. Both formats require CONSTANT_CASE for the key names by convention, matching how the host operating system exposes environment variables to running processes. A DATABASE_URL, REDIS_URL, or SECRET_KEY in your Compose file matches the variable name your application reads with os.getenv("DATABASE_URL") in Python or process.env.DATABASE_URL in Node.js. Using snake_case or camelCase here creates a mismatch between the configuration file and the application code that is hard to debug in production.

GitHub Actions env and secrets blocks

GitHub Actions workflow files use env: blocks at the job or step level to expose values as environment variables. By convention, all variables in env: blocks use CONSTANT_CASE: API_KEY, BASE_URL, DATABASE_URL. GitHub's own documentation uses this pattern throughout. Secrets defined in the repository settings are referenced as ${{ secrets.MY_SECRET }}, and secret names in the GitHub UI also use CONSTANT_CASE. Adopting this convention consistently across your workflow files and application code means the same name appears in both places without any case translation.

Consistency in naming reduces the cognitive load when moving between the workflow YAML and the application code that consumes those variables. A developer reading process.env.DATABASE_URL in Node.js can immediately locate the corresponding DATABASE_URL in the GitHub Actions env: block or the repository's secret store without mentally translating between casing styles.

Runtime variables versus compile-time constants in application code

Not all CONSTANT_CASE identifiers are constants in the strict language sense. Understanding the distinction prevents confusion when reading code that uses this naming pattern. The naming convention communicates intent to other developers rather than enforcing immutability at the language level, which means the reader must rely on the uppercase name as a signal that the value should not be reassigned during the program's execution.

In Python, any module-level variable can be named with SCREAMING_SNAKE_CASE, but the name signals intention rather than enforcement. A DATABASE_URL = os.getenv("DATABASE_URL") is technically a dynamic value read at import time, not a compile-time constant. Python developers use CONSTANT_CASE here because the value is stable for the lifetime of the process, even though it could change between runs. Tools like mypy or pyright do not enforce immutability based on name alone.

The naming convention communicates intent

CONSTANT_CASE tells the human reader: treat this as fixed, do not reassign it inside a function, and do not pass it as a mutable argument. In JavaScript, const prevents reassignment at the variable binding level, but CONSTANT_CASE naming adds the intent signal for values that are logically constant regardless of the const keyword. A const maxRetries = getConfig('maxRetries') is technically a constant binding but reads as a dynamic lookup; naming it MAX_RETRIES makes the intent explicit.

Try in the tool