SCREAMING_SNAKE_CASE — Constants, ENV Variables & Best Practices

What is SCREAMING_SNAKE_CASE?

SCREAMING_SNAKE_CASE (also called CONSTANT_CASE or UPPER_SNAKE_CASE) writes all words in uppercase and joins them with underscores. It combines the word-separation logic of snake_case with the visual emphasis of full uppercase.

Examples:

• MAX_RETRIES — maximum number of retry attempts
• API_BASE_URL — the root URL of an external API
• DEFAULT_TIMEOUT_MS — default network timeout in milliseconds
• HTTP_STATUS_NOT_FOUND — a numeric status code alias
• DATABASE_CONNECTION_LIMIT — pool size constant

The rationale is semantic: when a reader sees an all-uppercase identifier, they immediately know they are looking at a fixed value that will not change between the time a program starts and the time it ends. This is valuable information that removes mental overhead during code review.

Language-by-language usage

• Python: PEP 8 mandates SCREAMING_SNAKE_CASE for module-level constants. MAX_RETRIES = 3 at the top of a file. Class-level constants follow the same rule (class Config: DEBUG = False is common but not technically SCREAMING_SNAKE_CASE — it is just a class attribute).
• JavaScript / TypeScript: no official language mandate exists. The Airbnb Style Guide recommends SCREAMING_SNAKE_CASE for true constants — values that are fixed across the entire application lifecycle (API keys, timeout limits). It does not mandate it for every const declaration, because const in JS prevents reassignment of the binding but not mutation of the value.
• Java: the Java Language Specification and Google Java Style Guide both mandate SCREAMING_SNAKE_CASE for static final fields: public static final int MAX_POOL_SIZE = 50;
• C / C++: preprocessor macros use SCREAMING_SNAKE_CASE universally: #define MAX_BUFFER_SIZE 4096. This convention predates most modern languages and influenced the rest of the ecosystem.
• Rust: the compiler issues a warning for non-SCREAMING_SNAKE_CASE constant names (const and static items). The convention is enforced by the language toolchain.
• Go: Go does not use SCREAMING_SNAKE_CASE — all constants are PascalCase or camelCase (visibility is controlled by capitalisation). This is a notable exception to the cross-language convention.

Environment variables and .env files

Environment variables follow SCREAMING_SNAKE_CASE universally across all operating systems and tools. This is a POSIX convention: the shell historically reserved lowercase variable names for shell built-ins and user scripts, leaving uppercase for environment variables that are inherited by child processes.

• DATABASE_URL=postgres://…
• SECRET_KEY=abc123…
• NODE_ENV=production
• PORT=3000
• AWS_ACCESS_KEY_ID=…

When NOT to use SCREAMING_SNAKE_CASE

• Mutable state: if the value can change at runtime, use snake_case or camelCase. SCREAMING_SNAKE_CASE promises immutability; breaking that promise misleads readers.
• Every const in JavaScript: the const keyword prevents reassignment of the binding, not mutation of the object. const user = {} does not make user a constant in the semantic sense — the object can still be modified. Reserve SCREAMING_SNAKE_CASE for primitive constants and configuration values.
• Go identifiers: Go uses PascalCase/camelCase controlled by capitalisation for export visibility. Do not use SCREAMING_SNAKE_CASE in Go, even for constants — it is idiomatic to use MaxRetries or maxRetries.

Frequently asked questions