CONSTANT_CASE and Environment Variables: Why Capitals and Underscores

What CONSTANT_CASE is

CONSTANT_CASE writes every letter in capitals and joins the words with underscores: MAX_CONNECTIONS, API_BASE_URL, DEFAULT_TIMEOUT_SECONDS. It is also called SCREAMING_SNAKE_CASE and UPPER_SNAKE_CASE, names that describe how the capital letters look in a line of code. The style signals to the reader that a value is a constant: it is set once and should not be changed while the program runs.

The convention is old. C programmers wrote preprocessor macros in capitals to distinguish them from variables, and the habit spread to other languages. Today it is the standard style for constants in Python, Java, JavaScript, TypeScript, Rust and many others, and it is also the form used for environment variables on every major operating system.

Constants in code

Python has no real constants, but PEP 8 asks for constants to be written in capital letters with underscores at the top of a module. Java requires the keyword static final, and its code conventions ask for CONSTANT_CASE. JavaScript has const, and programmers use CONSTANT_CASE for values that are fixed and known at the start, but ordinary camelCase for values created by a calculation, even if they are declared with const. Rust uses the keyword const, and its compiler warns when the name of a constant or static is not in SCREAMING_SNAKE_CASE.

The style helps readers: when they see MAX_RETRIES in the middle of a function, they know it is not a local variable and can look it up in one place. It also makes search easier, as the capital letters stand out in code. A constant that is used in one place only might not need the style, but a constant with a meaning for the whole program does.

Environment variables

Environment variables are named values that the operating system passes to every program that starts: PATH, HOME, LANG, TEMP. By long-standing convention their names consist of capital letters, digits and underscores. The POSIX standard states that the names used by the standard utilities contain only uppercase letters, digits and underscores, and that lowercase names are reserved for applications. In practice almost everything uses capitals: DATABASE_URL, SECRET_KEY, NODE_ENV.

The convention makes variables easy to spot in a shell script or a configuration file, and it avoids clashes with ordinary shell variables, which are often lowercase. It is also a requirement for some tools: for example, frameworks that read configuration from the environment often expect a prefix in capitals, such as DJANGO_, VITE_ or NEXT_PUBLIC_.

Case sensitivity on different systems

On Linux and macOS, environment variable names are case sensitive: path and PATH are two different variables, and only PATH is used to find programs. On Windows, environment variable names are case-insensitive: Path, PATH and path refer to the same variable, although the system preserves the case in which it was first set.

This difference causes bugs in projects that run on both. A script that reads MyVar works on Windows even if the variable was set as MYVAR, and then fails on Linux. The safe rule is to use capitals everywhere, set the variable with exactly the name the program expects and test on the operating system where the program will run.

Common pitfalls

The first pitfall is mixing styles within one project, for example database_url in one file and DATABASE_URL in another. The second is letting secret values slip into a repository: environment variables are meant to keep secrets out of the code, but the file .env that holds them must be excluded from version control. The third is forgetting that a program reads its environment at start-up, so changing a variable does not affect programs that are already running.

A further pitfall is the Turkish locale problem, which affects code that converts names to capitals with a locale-sensitive function. In a Turkish locale, the lowercase i becomes a dotted capital İ, so a name such as title can turn into TİTLE and no longer match. Use a locale-independent conversion for identifiers, as explained in the article on case conversion in programming languages.

Naming good environment variables

Use clear, descriptive names with the service as a prefix: STRIPE_API_KEY is better than KEY. Use underscores, not hyphens, because most shells do not accept a hyphen in a variable name. Keep names short enough to type, but long enough that a colleague understands them without a comment. Group related variables with a common prefix, such as DB_HOST, DB_PORT and DB_NAME.

Boolean variables are best written in a way that leaves no doubt about the value, and the documentation should say whether the program accepts true, 1, yes or only one of them. Document every variable in a README or an example file, and give each a safe default where possible.

Converting a list to CONSTANT_CASE

When you have a list of settings in plain words, such as database host, database port and maximum retries, you can paste them into the converter, one per line, and click CONSTANT_CASE. Each line becomes a name in capitals with underscores: DATABASE_HOST, DATABASE_PORT, MAXIMUM_RETRIES. The tool also splits camelCase names, so maxRetries becomes MAX_RETRIES.

The tool changes the form of the names, not their meaning, so check each result against the documentation of the tool that will read the variable. A few frameworks ask for a specific prefix or a double underscore as a separator for nested settings, and these details must be added by hand.