"// TODO: There's a bug here, fix it later"

Leaving "TODO" comments in code ("// TODO: There's a BUG here, fix it later") is an art, an art that makes successors grit their teeth. It can infuse your code with a sense of mystery while planting landmines for team collaboration. If you want to turn your codebase into a labyrinth no one dares to touch, here are some "best practices."

2. The "Artful Use" of TODO Comments

TODO comments are a classic way to leave landmines. The essence lies in: Never fix it, but always remind. For example:

function calculatePrice(quantity, price) {
  // TODO: There's a BUG here—negative prices return positive results. Fix later.
  return quantity * Math.abs(price);
}

The brilliance of this code:

1. The issue is "clearly" noted but never resolved;
2. The logic brute-forces the problem with Math.abs, creating an even bigger pitfall;
3. When successors see the comment, they’ll be trapped in philosophical debate: "Should I fix it or not?"

Advanced technique: Add vague context to the comment, like:

// TODO: This logic is flawed, but it's tied to the backend API. Don't touch it yet.
const parseData = (data) => JSON.parse(data);

3. Turn "Temporary Fixes" into Permanent Problems

"Temporary solutions" are the golden excuse for leaving landmines. For example:

function fetchUserData(userId) {
  // Temporary fix: Hardcoded data until the backend API is ready.
  return userId === 1 ? { name: "Admin" } : null;
}

The destructiveness of this "temporary fix":

• It appears "good enough," so it stays forever;
• By the time the backend API is ready, no one remembers this hardcoded logic;
• If others build features relying on this, it creates even more dependency issues.

4. Plant "Time Bombs" in the Code

The pinnacle of leaving landmines is making problems explode under specific conditions. For example:

function validatePassword(password) {
  // Note: Skipping special char validation for launch. Add in V2.
  return password.length >= 6;
}

The issues with this code:

• Early testing might miss it because "length is enough";
• When the user base grows and security demands special char validation, you’ll find this logic embedded everywhere;
• If the comment is deleted, successors won’t even know there’s a landmine.

5. Mask Problems with "Known Issues" Documentation

A more advanced tactic than code landmines is documentation landmines. For example, add this to the project README:

## Known Issues
- Shopping cart occasionally calculates prices wrong in Safari (cause unknown, pending investigation).
- Avatar upload component doesn’t support PNG (legacy issue).

The "advantages" of this approach:

• Issues are "officially acknowledged," so no one fixes them;
• Successors will avoid these features instead of trying to fix them.

6. In Code Reviews, Insist "If It Works, Don’t Touch It"

When someone tries to fix your landmines, use these tactics to stop them:

• "This logic is weird, but it works in production. Leave it alone."
• "If you change this, what if it breaks something else?"
• "This is legacy code—none of us know why it was written this way."

7. Turn BUGs into "Features"

If a landmine is too big to ignore, rebrand it as a "feature." For example:

function formatDate(date) {
  // Note: Skipping timezone conversion intentionally—users prefer local time.
  return date.toLocaleString();
}

Then, in the requirements doc, write:

User feedback: Prefer dates in local time.
Solution: Already supported.

8. Leave "Mystery Code" in Critical Places

Randomly insert inexplicable logic, like:

function processOrder(order) {
  // Don’t ask why. Removing this will crash the system.
  if (order.items.length > 0) {
    order.items.push({ id: -1, name: "ghost item" });
  }
  // More logic...
}

The destructive power of this code:

• No one dares delete it because the comment says "it’ll crash";
• No one knows why this "ghost item" exists;
• If the business later needs an id: -1 item, it’ll spawn even weirder bugs.

9. Refuse to Write Unit Tests

Unit tests are the nemesis of landmines. To ensure longevity:

• Claim "The project is too rushed for tests";
• Or write useless tests, like:

test("calculatePrice should return a number", () => {
  expect(typeof calculatePrice(2, 3)).toBe("number");
});

Such tests:

• Satisfy coverage metrics;
• Do nothing to catch real issues (e.g., negative prices).

10. Blame "Browser Compatibility"

When a landmine is discovered, shift blame to browsers:

function openPopup(url) {
  // window.open fails on some Android devices. No solution yet.
  try {
    window.open(url);
  } catch (e) {
    console.log("Whatever, users won’t notice.");
  }
}

The "benefits":

• Browsers become the universal scapegoat;
• Issues are labeled "environmental," dropping their priority to zero.

11. Leave "Treasures" Before Quitting

If you’re about to leave the company, bury some landmines only you understand. For example:

function getServerConfig() {
  // Important: If you change this, contact @xxx (your email) first.
  return process.env.NODE_ENV === "production" ? PROD_CONFIG : DEV_CONFIG;
}

The power of this code:

• It looks like an environment check, but no one knows the difference between PROD_CONFIG and DEV_CONFIG;
• If someone touches it, you can gracefully reply: "I left a note, didn’t I?"