CONSTANT_CASE Converter

Transform text to CONSTANT_CASE format for programming constants.

Input

Output

Examples

Example 1

max retry count

Example 2

database-connection-string

Example 3

apiAccessToken

Understanding CONSTANT_CASE Convention

CONSTANT_CASE (also called SCREAMING_SNAKE_CASE) capitalizes all letters and separates words with underscores: 'maximum retry count' becomes 'MAXIMUM_RETRY_COUNT'. The all-caps formatting immediately signals unchanging values that should not be modified.

Visual distinction helps developers identify constants at a glance. 'API_BASE_URL' stands out from 'apiBaseUrl' in code, preventing accidental reassignment and clarifying which values are configuration versus runtime variables.

The convention combines uppercase visibility with underscore readability. Unlike 'MAXIMUMRETRYCOUNT' (unreadable) or 'Maximum_Retry_Count' (mixed case), pure CONSTANT_CASE balances scannability with word separation for clear, professional identifiers.

Where CONSTANT_CASE is Required

Environment variables universally use CONSTANT_CASE: 'DATABASE_URL', 'API_SECRET_KEY', 'PORT'. Operating systems, containers, and deployment platforms expect uppercase env vars, making CONSTANT_CASE the standard for configuration across all environments.

JavaScript and TypeScript constants follow this convention: 'const MAX_USERS = 1000', 'const DEFAULT_TIMEOUT = 5000'. While 'const' keyword declares immutability, CONSTANT_CASE naming reinforces that the value is a true constant, not just a non-reassignable variable.

Python globals and module-level constants use CONSTANT_CASE per PEP 8: 'PI = 3.14159', 'MAX_OVERFLOW = 100'. This distinguishes module constants from regular variables and functions which use lowercase snake_case.

Configuration files (JSON, YAML) often use CONSTANT_CASE for top-level keys: {MAX_CONNECTIONS: 50, TIMEOUT_SECONDS: 30}. This separates config constants from runtime data that might use camelCase or other conventions.

CONSTANT_CASE Conversion Pitfalls

Numbers within constants need careful handling. 'OAuth 2.0 Client ID' could become 'OAUTH_2_0_CLIENT_ID' or 'OAUTH_2_CLIENT_ID'. Periods in version numbers typically convert to underscores, but readability might favor 'OAUTH2_CLIENT_ID'.

Acronyms lose distinction when fully capitalized. 'API URL Handler' becomes 'API_URL_HANDLER'—the all-caps format makes it impossible to tell where acronyms end and words begin. Unlike mixed case, CONSTANT_CASE offers no visual acronym separation.

Very long constants become unwieldy. 'MAXIMUM_NUMBER_OF_CONCURRENT_DATABASE_CONNECTION_RETRIES' is technically correct but impractical. Excessive length harms readability—abbreviate or simplify before converting.

Special characters and symbols must be stripped or spelled out. 'API_KEY#1' cannot have '#' in identifiers—it becomes 'API_KEY_1' or 'API_KEY_NUMBER_1'. Decide whether to drop symbols silently or expand them to words.

Best Practices for Constant Naming

Reserve CONSTANT_CASE for true constants only: Values that never change at runtime (PI, MAX_SIZE, API_VERSION). Do not use for configuration that might be modified or calculated values that vary per execution.

Abbreviate thoughtfully to balance clarity and length: 'MAX_CONN' is acceptable for 'MAXIMUM_CONNECTIONS' in context, but 'MC' is too cryptic. Common abbreviations (MAX, MIN, NUM, ID) are widely understood.

Group related constants with prefixes: 'DB_HOST', 'DB_PORT', 'DB_NAME' cluster database config together. Prefixes create logical namespaces in flat constant lists, improving organization and discoverability.

Document magic numbers with named constants: Replace '86400' with 'SECONDS_PER_DAY = 86400'. CONSTANT_CASE makes these definitions searchable and self-documenting, eliminating mysterious hardcoded values from algorithms.

Loading tool…