Hardcoded Configuration

Storing config in the codebase instead of the environment.

“Store config in the environment.” – 12-Factor App

Signs of Use (Symptoms)

  • const DB_HOST = "prod-db.aws.com"; in source code.
  • API keys committed to Git.
  • Config values that require a rebuild to change.

Why it is bad (Consequences)

  • Security: Secrets in Git history forever.
  • Rigidity: Can’t change config without redeploying code.
  • Environment Coupling: Dev code points to Prod resources.

Why it happens (Root Cause)

Easier to hard code than set up environment variable handling.

When it might be okay (Exceptions)

  • Truly static, non-sensitive values (e.g., Pi, mathematical constants).

Explanation

Problem

Production database URL is in config.ts. It’s in Git. It can’t be changed per environment.

The Flaw

Code and config are different concerns. 12-Factor App: store config in environment.

Real world analogy

Printing your home address directly on every letter instead of using a return address label you can change.

Refactoring Solution

  • Use Environment Variables: process.env.DB_HOST.
  • Externalize config files: .env, dotenv, Kubernetes ConfigMaps.

Pros and Cons (of the Antipattern)

Pros (Why people do it) Cons (The price you pay)
  • Simple
    		•
  • Security risk
  • Inflexibility
    		•

    Comparison

    • Related Antipatterns: None directly.
    • Related Principles: 12-Factor III. Config.

    Code example

    Typescript

    Bad (The Antipattern)

    Good (The Fix)

    PHP

    Good (The Fix)