CONSTANT_CASE

What CONSTANT_CASE means

CONSTANT_CASE — also called SCREAMING_SNAKE_CASE or UPPER_SNAKE_CASE — writes identifiers in all uppercase letters with words separated by underscores. The convention is universal across languages for one specific purpose: marking values that don't change at runtime. Constants, environment variables, compile-time macros, configuration keys that are baked into the program.

The convention is intentionally visually loud. When you see MAX_RETRY_COUNT next to retryCount in source code, the all-caps signals immediately that one is a fixed value and the other is a variable. This visual contrast is the whole point of the convention.

Where CONSTANT_CASE is canonical

• Constants in C, C++, Java, JavaScript: const int MAX_USERS = 1000;, public static final int DEFAULT_TIMEOUT = 30;. While JavaScript's const keyword can apply to any binding, the convention reserves CONSTANT_CASE for truly immutable, top-level configuration values — not for any const declared variable.
• Environment variables: DATABASE_URL, API_KEY, NODE_ENV. Unix conventions for environment variables go back to the 1970s. Tools like dotenv, Docker, and Kubernetes all expect CONSTANT_CASE for env var names.
• C preprocessor macros: #define MAX_LINE_LENGTH 1024. The convention distinguishes macros (textually substituted at compile time) from functions and variables.
• Python module-level constants: PEP 8 specifies that "constants are usually defined on a module level and written in all capital letters with underscores separating words." Examples: MAX_OVERFLOW, TOTAL.
• Java static final fields: the official Java code conventions mandate CONSTANT_CASE for any field declared with both modifiers.
• HTTP header names: while not strictly identifiers, headers like CONTENT_TYPE appear in this form in environment-variable-style representations (especially in CGI and WSGI contexts).

The semantic weight of all-caps

CONSTANT_CASE is one of the few conventions where the formatting carries genuine semantic meaning, not just stylistic preference. In a Python codebase, a name like MAX_CONNECTIONS tells the reader: this is a module-level constant, set once and never reassigned. A name like max_connections tells the reader: this is a local variable, regular state.

Mixing the conventions destroys this signal. A developer who uses MAX_CONNECTIONS for a value that mutates during runtime is committing a stylistic crime that confuses readers and tools alike. Linters in most languages explicitly check that names matching the constant pattern are actually constant.

Edge cases in conversion

• Already-uppercase input: HTML PARSER becomes HTML_PARSER, with whitespace folded to underscore.
• Mixed-case acronyms: XMLHttpRequest becomes XML_HTTP_REQUEST. Tokenization recognizes the acronym run.
• Numbers: html5 parser becomes HTML5_PARSER. Numbers stay attached to their preceding word.
• Special characters: typically stripped or replaced. user@email becomes USER_EMAIL, not USER_AT_EMAIL — though that's a choice, and some style guides spell out the character names.

CONSTANT_CASE versus other conventions

The closest relative is regular snake_case, which differs only in case. Both use underscores as separators; snake_case is lowercase, CONSTANT_CASE is uppercase. The pair is often used intentionally within one codebase: get_user_id (function), user_id (variable), MAX_USER_ID (constant). The visual hierarchy mirrors the semantic hierarchy.

JavaScript's situation is unusual. The language has both const (which creates immutable bindings) and the CONSTANT_CASE convention (which signals immutable top-level configuration). Not every const declaration uses CONSTANT_CASE — only the subset that represents true constants, typically declared at module scope and serving as configuration. Local const declarations inside functions use regular camelCase.

When NOT to use CONSTANT_CASE

For values that might change. For function parameters. For class members other than static finals. For anything inside a function body unless it's a literal-substitution constant. The convention's power comes from its narrow application — if everything is in CONSTANT_CASE, nothing is special.

Environment variable names in .env files are an exception: every name should be CONSTANT_CASE regardless of whether the value is technically constant. The convention there isn't about immutability — it's about matching the universal env var convention so tools parse correctly.