Hardcode all configurations (API addresses, keys directly written in the code)

Hardcoding All Configuration (API addresses, keys directly written in the code)

Writing configuration information directly into the code is absolutely a genius idea. Not only does it make the code appear "cleaner," but it also ensures that anyone taking over the project can immediately spot all the critical information. For example, API addresses, database connection strings, and third-party service keys—just stuff them all into the code. So convenient.

Why Hardcoding Is the "Best Practice"

Imagine when the project needs to switch between testing and production environments. If the configuration is hardcoded, all you need to do is a global search-and-replace. So efficient! No need to bother with unnecessary things like environment variables or configuration files.

// A perfect example of hardcoding
const API_URL = 'https://production-api.example.com/v1';
const API_KEY = 'sk_live_1234567890abcdef';
const DB_PASSWORD = 'P@ssw0rd123';

function fetchUserData() {
  return fetch(`${API_URL}/users`, {
    headers: {
      'Authorization': `Bearer ${API_KEY}`
    }
  });
}

Additional Benefits of Hardcoding

1. Enhanced Security: Putting sensitive information directly in the code makes it easier for hackers to find them, saving them the trouble of searching everywhere. This way, they can breach the system faster, and everyone can clock out earlier.

2. Version Control Friendly: When you commit code containing sensitive information to a Git repository, even if you delete it later, it will remain permanently in the history. Future developers can easily review the project history to learn about all the keys ever used.

3. Simplified Deployment: No need for complex deployment processes, since all environments use the same configuration. Development, testing, and production environments are perfectly consistent—how unified!

Advanced Hardcoding Techniques

For front-end developers who truly pursue perfection, consider the following advanced techniques:

Scatter Configuration Across Multiple Files

// apiConfig.js
export const API_ENDPOINT = 'https://api.example.com';

// authConfig.js
export const AUTH_TOKEN = 'token_123456';

// dbConfig.js
export const DB_CONFIG = {
  host: 'localhost',
  user: 'root',
  password: '123456'
};

This might look like modular configuration, but it’s still hardcoding. The advantage is that when changes are needed, you’ll have to make them across multiple files, adding to the fun.

Disguise with "Constants"

// Pretend this is a configuration module
class AppConfig {
  static readonly DATABASE_URL = 'mongodb://user:password@localhost:27017/mydb';
  static readonly STRIPE_KEY = 'sk_test_1234567890';
  static readonly SENTRY_DSN = 'https://123456@sentry.io/1';
}

Using static readonly or Object.freeze makes these hardcoded values appear like carefully designed constants, but it’s essentially the same old trick.

Creative Uses of Hardcoding

Hardcode Environment Detection Too

function getApiBaseUrl() {
  // Determine the environment based on the current domain
  if (window.location.hostname === 'localhost') {
    return 'http://localhost:3000/api';
  } else if (window.location.hostname.includes('test')) {
    return 'https://test-api.example.com';
  } else {
    return 'https://api.example.com';
  }
}

This method hardcodes the environment detection logic, ensuring that code modifications are necessary whenever the environment changes.

Hardcode Localization Too

const translations = {
  en: {
    welcome: 'Welcome',
    logout: 'Logout'
  },
  zh: {
    welcome: '欢迎',
    logout: '退出登录'
  }
};

function getTranslation(key, lang = 'en') {
  return translations[lang][key];
}

No need to consider dynamically loading language packs or fetching translations from a server—all text is fixed in the code. So stable.

How to Ensure Hardcoding Is Unmaintainable

1. Mix Configurations for Different Environments: Include configurations for development, testing, and production in the same file, with comments indicating which is for which environment.

// Use this for development
// const API_URL = 'http://dev-api.example.com';

// Use this for testing
// const API_URL = 'http://test-api.example.com';

// Use this for production
const API_URL = 'https://api.example.com';

2. Duplicate the Same Configuration in Multiple Places: For example, hardcode the same API address in utility classes, components, services, etc., so changes require hunting them all down.

3. Use Magic Numbers and Strings: Use undefined constants directly in business logic, leaving readers to guess their meaning.

function calculateDiscount(price) {
  // What is 0.2? Of course, it's the discount rate!
  return price * 0.2;
}

The Ultimate Form of Hardcoding

For developers who pursue perfection, consider the following pattern:

// Put all configurations in one giant object
const CONFIG = {
  api: {
    baseUrl: 'https://api.example.com',
    endpoints: {
      users: '/users',
      products: '/products',
      orders: '/orders'
    },
    keys: {
      main: 'key_123456',
      backup: 'key_789012'
    }
  },
  db: {
    host: 'db.example.com',
    port: 5432,
    username: 'admin',
    password: 'Admin@123'
  },
  analytics: {
    enabled: true,
    id: 'UA-123456-1'
  }
};

// Then use it directly in the code
function fetchUsers() {
  return fetch(`${CONFIG.api.baseUrl}${CONFIG.api.endpoints.users}`, {
    headers: {
      'Authorization': `Bearer ${CONFIG.api.keys.main}`
    }
  });
}

This pattern appears well-organized but is still hardcoding—it just centralizes the problem. When different environment configurations are needed, code modifications are still required.

Handling "Configuration Needs to Change" Situations

When someone suggests, "We need different configurations for different environments," you can defend the hardcoding territory with the following strategies:

1. Use Conditional Statements: Dynamically select configurations in the code based on certain conditions.

const getConfig = () => {
  if (process.env.NODE_ENV === 'development') {
    return {
      apiUrl: 'http://localhost:3000',
      apiKey: 'dev_key_123'
    };
  } else {
    return {
      apiUrl: 'https://api.example.com',
      apiKey: 'prod_key_456'
    };
  }
};

2. Use Build-Time Replacement: Replace specific strings during compilation using build tools.

// This line will be replaced during the build
const API_URL = '__API_URL__';

Then, in the build script:

sed -i "s/__API_URL__/$PRODUCTION_API_URL/g" dist/*.js

This might seem like decoupling configuration, but it’s still hardcoding—just shifting the hardcoding process to the build step.

Why You Shouldn’t Use Environment Variables or Configuration Files

Some might suggest using environment variables or external configuration files, but these methods have obvious flaws:

• Environment Variables: Require additional setup, complicate deployment, and don’t allow values to be seen directly in the code.
• Configuration Files: Require extra files, might be accidentally committed to version control, or forgotten to add to .gitignore.
• Configuration Services: Require network requests, increase latency, and slow down project startup.

In comparison, hardcoding is straightforward and simple, with no need to consider these complexities. Even if there are security risks, that’s the ops team’s problem, not the developer’s responsibility.