The HotfixHero code Manifesto: Seven Rules to Live By

Source: Dev.to

Introduction

I hear you. You want the technical specifications on how to stop being an embarrassment to your team. Fine. Writing code that scales and doesn’t induce chronic migraines is all about discipline, not magic. Forget your complex patterns for a second—master the basics first.

Here are the seven commandments I live by. Read them, implement them, and maybe, just maybe, your code review won’t look like a war‑crime report.

1. DRY (Don’t Repeat Yourself)

Every piece of logic, every business rule, and every data definition must live in exactly one place. If you copy‑paste, you’re not coding; you’re creating technical debt. The cost of fixing a bug multiplies by the number of times you repeated yourself. That’s a terrible ROI.

Bad Example (Duplicate Validation)

function createUser(data) {
  if (data.password.length  // The goal is to solve the problem, not win a Turing Award for the most convoluted solution. Simple code is cheaper to maintain, easier to test, and less likely to introduce subtle bugs. Your complexity doesn't impress anyone but junior developers.

Bad Example (Overly Complex Conditional)

function getDiscount(user) {
  let status = user.isPremium ? 0.20 : 
               (user.totalOrders > 5 && user.joinedYear  10 ? 0.10 : 0;

  // Now try debugging that nested ternary hell at 3 AM.
  return status;
}

HH Way (Using Clear Logic)

function getDiscount(user) {
  if (user.isPremium) {
    return 0.20;
  }

  if (user.totalOrders > 5 && user.joinedYear  10) {
    return 0.10;
  }

  return 0; // The default, simple case
}

3. YAGNI (You Aren’t Gonna Need It)

Stop guessing what the Product Owner might ask for next year. Build only what is required today. Every line of code you write that isn’t solving a current problem is wasted time and creates unnecessary complexity.

Bad Example (Pre‑building for Future Features)

# The current requirement is only 'File' storage.
# The developer adds hooks for 'S3' and 'Azure' just in case.
class StorageManager:
    def __init__(self, storage_type='FILE'):  #  A class or function should have only **one** reason to change. If your function is responsible for fetching data, formatting it, and sending an email, it’s doing too much. When the email format changes, the fetching function shouldn’t have to change.

Bad Example (God Function)

function processAndFormatUserData(id) {
  // 1. Fetch data (reason to change: database schema)
  const user = database.fetchUser(id); 

  // 2. Calculate Age (reason to change: calculation logic)
  const age = new Date().getFullYear() - new Date(user.dob).getFullYear();

  // 3. Format output (reason to change: UI/API requirement)
  return { id: user.id, fullName: `${user.first} ${user.last}`, age };
}

HH Way (Separated Responsibilities)

// 1. Data Retrieval
function fetchUserFromDB(id) {
  return database.fetchUser(id);
}

// 2. Business Logic / Calculation
function calculateAge(dob) {
  return new Date().getFullYear() - new Date(dob).getFullYear();
}

// 3. Formatting / Presentation
function formatUserPresentation(user) {
  return {
    id: user.id,
    fullName: `${user.first} ${user.last}`,
    age: calculateAge(user.dob) // Calls focused logic
  };
}

5. Separation of Concerns

Divide an application into distinct features that overlap as little as possible. Your data‑access layer shouldn’t know about HTTP request headers, and your controller shouldn’t contain complex formatting logic.

Bad Example (Mixing Data Access and Business Logic)

// Inside a Web Controller/Endpoint
@GetMapping("/users/{id}")
public UserDetails getUserDetails(@PathVariable Long id) {
    // Concern 1: Database Access is mixed here
    UserEntity user = entityManager.find(UserEntity.class, id); 

    // Concern 2: Business Logic is mixed here
    if (user.getBalance()  // Optimize only when you have evidence that a piece of code is a bottleneck. Writing clever, low‑level loops for the sake of “speed” often sacrifices readability and maintainability.

Bad Example (Unnecessary Low‑Level Loop for Readability Sacrifice)

// Bad: Using a manual `for` loop where a higher‑level method would be clearer
let result = [];
for (let i = 0; i  item.active);

Conclusion

Master these fundamentals, and you’ll spend far less time fighting your own code and far more time delivering value. The principles above are timeless—apply them consistently, and your future self (and your teammates) will thank you.

Length Decrement for Micro‑Optimization

Less readable than native methods, and modern engines optimize map and forEach just as well.

let i = items.length;
while (i--) {
  processed.push(items[i].toUpperCase());
}

HH Way (Readable and Maintainable)

Good: Clear intent, relies on optimized built‑in methods.

// Using the built-in `map` method
const processed = items.map(item => item.toUpperCase());

Law of Demeter (Principle of Least Knowledge)

“Don’t talk to strangers.”
An object should only communicate with its immediate friends (objects it created, its parameters, its properties).
Reaching through a chain of methods couples your code to deep internal structures, making it brittle.

Bad Example (Method‑Chaining Violation)

// We are asking the `user` object for its `wallet`, then the `wallet` for its `card`,
// then the `card` for its `security code`. Too much knowledge.
String code = user.getWallet()
                  .getPrimaryCard()
                  .getSecurityCode();

HH Way (Delegation)

// We only ask the `user` to perform the action. The `user` object handles the internal structure.
String code = user.getSecurityCodeForPrimaryCard();