Hardcoding embeds a value directly in code or a fixed artifact rather than obtaining it dynamically. It is useful for a short-lived stub or UI prototype, but it becomes risky when the value is configuration, credentials, infrastructure details, or production data. section 3.7 section 4.3 section 6.4
Choose the treatment based on what the value represents:
- Use hardcoded responses temporarily to confirm that an API route works before a database exists. section 4.3
- Use hardcoded sample rows during short UI cycles, then replace them with a mocked API call; include edge-case amounts such as trailing zeros and values above 999. section 6.4
- Avoid embedding usernames, passwords, ports, servers, and similar configuration throughout code. These values can expose secrets and make later changes difficult to locate and test. section 3.7
- Do not treat hardcoded login users or tokens as real authentication. A basic credential example can demonstrate flow, but API access still needs token validation. section 7.7
Move database credentials out of application code
Place PostgreSQL credentials in an environment file, keep that file out of source control with gitignore, and read the values through environment variables when constructing the database connection. Document the required variables so new deployments can be configured reliably. section 3.7
import os … POSTGRES_USER = os.getenv("POSTGRES_USER") POSTGRES_PASSWORD = os.getenv("POSTGRES_PASSWORD") … DATABASE_URL = f"dbname={POSTGRES_USER} user={POSTGRES_USER} ➥ password={POSTGRES_PASSWORD} host=postgres port=5432"
This connection setup reads PostgreSQL credentials from environment variables instead of embedding them in the API container. section 3.7
